400 Bad Request

The server cannot process the request because of a client-side error such as malformed syntax, invalid framing, or corrupted request data.

Defined in RFC 9110 §15.5.1

What 400 means

The 400 Bad Request status is the generic client-error response in RFC 9110: the server cannot or will not process the request because it perceives a client-side problem such as malformed request syntax, invalid message framing, or deceptive request routing. Unlike more specific 4xx codes, 400 does not say what exactly is wrong; the response body is expected to carry the details. It applies before the server has even attempted to act on the request's semantics, so a 400 usually means the request itself is broken, not that the resource or authorization is the issue.

In practice, 400 responses are dominated by a handful of parsing failures. APIs that expect JSON reject bodies with trailing commas, unescaped characters, or truncated payloads from a dropped connection. Form submissions fail when required fields are missing or a multipart boundary is malformed. Oversized request headers, such as long cookies, verbose custom headers, or bloated JWTs stuffed into an Authorization header, trip server-level buffer limits like nginx's large_client_header_buffers before the application code ever runs. Because these failures happen at the framing layer, they are often invisible in application logs and only show up in the web server's own error log.

Cookies are a frequent and underappreciated cause: a browser can send a corrupted, oversized, or improperly encoded cookie header that the server's HTTP parser rejects outright, producing a 400 with no application code involved at all. This is common after a cookie-format change on the server side, when old client-stored cookies no longer parse cleanly. Query strings with invalid percent-encoding, unbalanced brackets, or stray null bytes cause similar failures. Because the error originates below the application layer, clearing cookies and site data is often the fastest fix for browser users encountering a 400 on a site that otherwise loads fine.

400 is easy to confuse with 422 Unprocessable Content: a 400 means the request could not even be parsed or understood, while a 422 means it was parsed correctly but fails validation rules, such as a well-formed JSON body with a value out of range. Getting this distinction right in API design helps consumers debug faster, since a 400 points them at the wire format and a 422 points them at their data. Well-behaved APIs return a response body describing exactly which part of the request failed, rather than a bare status code with no context.

Common causes

A request body contains malformed or truncated JSON that the parser cannot decode.
The client sends a cookie header that is corrupted, oversized, or uses an outdated format the server can no longer parse.
Request headers collectively exceed the size limit configured on the web server or reverse proxy.
The Content-Type header does not match the actual structure of the body, so the wrong parser is invoked.
A query string contains invalid percent-encoding, unbalanced brackets, or illegal characters.
Multipart form data has a missing or mismatched boundary, truncating the parsed fields.

How to fix a 400

If you are the client (browser user or API caller)

Validate JSON payloads locally, ideally against a schema, before sending them, to catch syntax errors early.
Clear browser cookies and site data if the error appears sitewide, since a stale or oversized cookie can trigger it.
Confirm the Content-Type header accurately describes the body being sent.
Trim unnecessary custom headers and shrink oversized tokens, like a bloated JWT, that push total header size past server limits.
URL-encode query parameters and path segments correctly instead of hand-building the string.

If you run the server

Return a response body that names the specific validation or parsing failure instead of a bare 400.
Raise header and buffer size limits, such as nginx's large_client_header_buffers and client_header_buffer_size, only as far as genuinely needed.
Validate and sanitize input as early as possible in the request pipeline, before business logic runs.
Log the raw offending request, headers and body, for malformed traffic to speed up debugging.
Adopt JSON Schema or a similar validation layer at the API boundary so failures are consistent and well described.

Example

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

{"item": "widget", "qty": 3,}

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

{"error": "invalid_json", "message": "Unexpected trailing comma at position 29"}

A trailing comma in the JSON body makes the request unparseable, so the server rejects it before touching business logic.

Try it live

Our free status responder returns a real HTTP 400 you can point tests, monitors or a browser at.

GET https://mcp.httpstatus.com/status/400