400 Bad Request
The server will not process the request because something about it is malformed.
Status
HTTP/1.1 400 Bad Request
Details
- Category: 4xx
- Status: Standard. Registered with IANA and defined by a current standards-track RFC.
- Specification: RFC 9110 §15.5.1
- Cacheable: Only with explicit cache headers
- Response body: Allowed
- Retry: Retry only after changing the request
400 covers anything the server considers a client-side defect it cannot classify more precisely: invalid syntax in the request line, a malformed body, a header the parser rejects, or a framing error. It is the general-purpose client error, and a well-behaved API narrows it to something more specific whenever possible.
Because it is a catch-all, the body matters. A 400 that does not say which field or header was wrong forces the caller to guess, and guessing is what turns a five minute fix into an afternoon.
Common causes
- JSON, XML, or form data that does not parse, including a truncated body or a Content-Length that disagrees with what was sent.
- An invalid or oversized header, a bad cookie, or illegal characters in the URL.
- A missing required parameter, or a parameter whose type the server refuses to coerce.
- TLS or protocol confusion, such as sending a plaintext request to a port that expects TLS.
How to fix it
As the client
- Read the response body. Most APIs name the offending field there.
- Reproduce the exact request with curl -v and compare it byte for byte against a request that works.
- Clear cookies for the site. An oversized or corrupt cookie is a frequent cause of a 400 that appears only in one browser profile.
- Check URL encoding. Unencoded spaces, braces, and pipes in query strings are rejected by strict servers.
As the server
- Return a machine-readable error body naming the field and the rule that failed.
- Use a more specific code when one fits: 401, 403, 404, 409, 413, 415, or 422.
- Log the raw request when rejecting so the cause can be diagnosed without asking the client to reproduce it.
Examples
POST /api/v2/order HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"quantity": }
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
{"error":"invalid_json","detail":"Unexpected token } at position 13"}
Notes for proxy users
A proxy can produce a 400 of its own when the request it is asked to forward is malformed at the proxy layer, for example a CONNECT request to a host it cannot parse or a request line with an absolute URL it rejects. If the same request succeeds directly but fails through the proxy, suspect the request line and header formatting rather than the target site.