Developer Toolbox
About

400 Bad Request

The server won't process the request because something in it is malformed: the syntax, the framing, or a parameter it can't make sense of.1 The problem is on the client side, so sending the same request again gets the same answer.

  • Class 4xx client error
  • Retry not as is
Open JSON Formatter Find the syntax error in the request body.

Common causes

  • Invalid JSON in the body: a trailing comma, single quotes, an unescaped line break inside a string.
  • A Content-Type that doesn't match the body, such as JSON sent as application/x-www-form-urlencoded.
  • A malformed URL: a raw space, or a % that doesn't start an escape sequence.
  • A header the server rejects, or cookies grown too large. The code for that is 431,2 but some servers answer 400.
  • A required query parameter that is missing or has the wrong type.

How to fix it

  • Read the response body first. Most APIs name the field that failed, often in an application/problem+json document.3
  • Validate the JSON you send. Building the body with JSON.stringify instead of string concatenation removes a whole class of these errors.
  • Compare the failing request with one that works: the headers, the encoding, and the exact bytes of the body.
  • If it only happens in one browser, clear the site's cookies: an oversized Cookie header is a common cause.

400 or 422?

Use 400 when the request can't be parsed at all (broken JSON, bad framing) and 422 when it parses but the values fail validation (an email without an @, an end date before the start).4 Many APIs use 400 for both, which is allowed, but the split tells the client whether to fix the syntax or the data.

Example

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "title": "Malformed JSON",
  "status": 400,
  "detail": "Unexpected token } in JSON at position 41"
}

Sources

  1. 1 RFC 9110, HTTP Semantics, section 15.5.1. rfc-editor.org ↩︎
  2. 2 RFC 6585, Additional HTTP Status Codes, section 5. rfc-editor.org ↩︎
  3. 3 RFC 9457, Problem Details for HTTP APIs. rfc-editor.org ↩︎
  4. 4 RFC 9110, HTTP Semantics, section 15.5.21. rfc-editor.org ↩︎