HTTP 400 Bad Request – What It Means and How to Fix It
Learn what HTTP 400 Bad Request means, what malformed requests trigger it, how it differs from 422 and 500, and how to diagnose one quickly.
A 400 is the server saying it could not understand the request well enough to act on it. Unlike a 403 or a 429, this one is genuinely your fault — the request was malformed before any business logic ran, and no amount of retrying an identical request will change the outcome.
1. What Does HTTP 400 Mean?
400 Bad Request indicates the server cannot or will not process the request because of something the client got wrong.
- Key idea: the request itself is defective — syntax, framing, or structure.
- Mechanism: parsing or validation fails before the handler executes.
- Retry semantics: pointless. The same bytes will fail identically.
The specification is deliberately broad here, so 400 has become the catch-all for client error in the same way 500 is for server error. Many APIs return 400 for validation failures that arguably deserve 422.
2. Common Causes
Malformed JSON. A trailing comma, a single quote, an unescaped newline inside a string, or a truncated body. The most frequent cause by a wide margin.
Missing required fields. The body parsed fine but omitted something mandatory.
Wrong content type. Sending JSON with Content-Type: application/x-www-form-urlencoded, or omitting the header entirely so the server guesses wrongly.
Invalid query parameters. A string where an integer is expected, an out-of-range value, or an unknown parameter on an API configured to reject extras.
Bad URL encoding. Unescaped spaces, stray % characters, or double-encoded values. % followed by anything other than two hex digits is invalid.
Oversized headers. Accumulated cookies pushing the header block past the server's limit. Some servers answer 400, others 431.
Invalid request line. Rare from libraries, common from hand-built raw sockets — a bad method, malformed HTTP version, or missing Host on HTTP/1.1.
Wrong body for the method. A GET carrying a body that a strict server refuses.
3. How to Diagnose It
Read the response body. Well-built APIs name the offending field. A 400 that says {"error":"invalid value for 'limit'"} has already told you the answer, and skipping this step is the most common wasted hour.
Validate your JSON independently. Pipe the exact payload through a parser before blaming the server. If your own language cannot parse it, neither could theirs.
Log the raw request as sent, not as intended. Serialisation bugs live between the two. A field that is None in your code may be emitted as null, "None", or omitted entirely, and only one of those is what you meant.
Check Content-Type against the body. These disagree more often than anyone expects, especially when a helper library sets one and you set the other.
Reproduce with curl. If a hand-built curl succeeds and your client fails, the difference is in your client's serialisation, not the API.
Compare against a working request. Diff the two. The discrepancy is usually one field or one header.
4. How to Fix It
Fix the payload, not the transport. 400 is a content problem, so rotating IPs, changing user agents, or adding delays achieves nothing.
Validate before sending. Build the request from a typed structure and serialise it, rather than assembling strings by hand.
Set Content-Type explicitly to match what you are actually sending.
URL-encode parameters properly using your language's encoder rather than string concatenation.
Trim cookies if headers are large — long-lived sessions accumulate them.
As an API author: return which field failed and why. A bare 400 with an empty body is technically valid and practically useless, and it converts a thirty-second fix into an afternoon of guessing.
5. HTTP 400 vs Related Status Codes
| Code | Meaning | Whose fault |
|---|---|---|
| 400 Bad Request | Malformed or unparseable request | Client |
| 422 Unprocessable Entity | Well-formed but semantically invalid | Client |
| 401 Unauthorized | Not authenticated | Client |
| 403 Forbidden | Authenticated but refused | Policy |
| 415 Unsupported Media Type | Content type not accepted | Client |
| 431 Request Header Fields Too Large | Headers too big | Client |
| 500 Internal Server Error | Server crashed handling it | Server |
The 400-versus-422 line is the one worth getting right as an API author: 400 means I could not parse this, 422 means I parsed it and the values are wrong. Conflating them tells the client nothing about where to look.
6. Real-World Examples
- A request that works in Postman and 400s from code. Postman set
Content-Typeautomatically; the client did not. - 400 only for certain records — one field contains a character that breaks unescaped string interpolation.
- 400 after adding a new optional field to an API that rejects unknown parameters by default.
- Intermittent 400s at scale — a serialisation race producing truncated bodies under concurrency.
- A scraper 400ing on a JSON endpoint because it sent form-encoded data copied from a different endpoint on the same API.
7. Summary
400 Bad Request means the server could not understand the request. It is a client-side problem, it will not resolve on retry, and the fix is always in what you sent rather than how often or from where you sent it.
Read the response body first, validate the payload independently, and log the request exactly as transmitted rather than as you believe you constructed it. Most 400s come down to malformed JSON, a mismatched Content-Type, or a parameter of the wrong type — and all three are visible the moment you compare a failing request against a working one.