400 Bad Request

This is an educational reference page about HTTP 400 Bad Request. The page itself is served as 200 OK so it can be indexed as HTTP documentation.

The server cannot or will not process the request because of something it sees as a client error, such as malformed syntax, invalid framing, or deceptive routing.

Specification

Registered in the IANA HTTP Status Code Registry as Bad Request. Defined in RFC 9110, Section 15.5.1.

What it means

HTTP 400 Bad Request means the server will not process the request because of a client error. RFC 9110 gives malformed syntax, invalid message framing, and deceptive request routing as examples. In APIs, 400 is the usual response for JSON that does not parse, missing required parameters, and query strings the server cannot read.

When to use it

Return 400 when the request body does not parse, such as broken JSON or a truncated multipart upload.
Return 400 when a required query parameter or header is missing or has the wrong type.
Use 415 when the Content-Type is not supported, 413 when the body is too large, and 422 when the body parses but the values fail validation.

Common causes

Malformed JSON, form data, or query strings.
Missing required parameters or the wrong data type for a field.
Oversized or malformed cookies or headers. Some servers answer 400 here, others 431.
A client library that sends a body with the wrong encoding.

How to fix it

Read the response body. A well-built API says which parameter or line failed.
Validate JSON before sending it, and check that Content-Type matches the body.
Clear cookies for the site when a browser gets 400 on every page. An oversized or corrupted cookie is a common cause.

Examples

Malformed JSON

POST /api/orders HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"sku":"A-100","quantity":2,

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

{
  "type": "https://api.example.com/problems/malformed-json",
  "title": "Request body is not valid JSON",
  "status": 400,
  "detail": "Unexpected end of input at line 1, column 29."
}

Common mistakes

Using 400 for every client error. 401, 403, 404, 409, 413, 415, 422, and 429 each tell the client something more specific.
Returning 400 with no body. The client cannot tell what to fix.
Echoing raw input back in the error message without escaping it.

Developer notes

Teams split 400 and 422 differently. A common rule is 400 when the server cannot parse the request and 422 when it can parse it but the values break a rule. Pick one rule, write it down, and use it everywhere in the API.

Questions

What does HTTP 400 Bad Request mean?

HTTP 400 means the server will not process the request because of a client error, such as malformed syntax or invalid framing.

Should invalid JSON return 400 or 422?

Invalid JSON should return 400 because the server cannot parse it. Use 422 when the JSON parses but the values fail validation.

Why do I get 400 Bad Request in the browser?

Common causes are a malformed URL, an oversized or corrupted cookie, or a request a browser extension modified. Clearing the site's cookies fixes many cases.

Header and content rules

RFC 9110 adds no header or content rule specific to 400. The 4xx class rules also apply. See 400 in the response obligations table.

Related comparisons

400 vs 411 vs 413 vs 422 Request Errors

Related API error guide

Use RFC 9457 Problem Details to add a standard application/problem+json body without changing the meaning of HTTP 400.