HTTP 400 Bad Request – Free, Online, Private

What HTTP 400 means

400 says the request is invalid in a way the server does not want to classify more tightly. Malformed JSON, a missing required field, and a query string that fails validation all land here when no more specific 4xx fits. The body should say what is wrong, in a form the client can show. A bare 400 with no explanation forces the caller to guess.

400 Bad Request belongs to the 4xx client error class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 400

When you see HTTP 400 Bad Request, stop on that exact status line. 400 Bad Request means the server could not understand the request, or it was malformed. The trace that usually produces it: The JSON body had a trailing comma or the wrong content type was parsed as JSON. The 4xx client error class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 400 for syntax and validation failures that are the client's fault and are not better described by 422, 415, 411, or 413. Use 422 when the syntax is fine and the instruction is impossible. Use 401 when the problem is authentication. Do not return 400 for a bug in your own code. That is 500.

How to fix HTTP 400

To fix HTTP 400, change the condition that made the server choose Bad Request. Do not retry the same bytes. Fix the request. A retry without a change will fail again and can trip a rate limit. Retrying an unchanged 400 is pointless. Retry after you correct the request. If the log line is a different code, leave this page. The mix-up people make with 400 is this one: 422 is often a better fit for a semantically invalid but well-formed document. 415 is the wrong media type. 500 is your bug, not the client's.

• A required query parameter was missing.
• A framework returned 400 for an exception that was actually a server bug.
• The error body named an internal class name and leaked an implementation detail.

An access log that only stores 400 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

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

{"error":"name is required"}

The status says the client can fix the request. The body says how. Keep the message stable enough to branch on if you do not offer a machine-readable code. Do not include the raw body the client sent if that body might contain a password.

What the client should do

Do not retry the same bytes. Fix the request. A retry without a change will fail again and can trip a rate limit.

Do not cache a 400 as the representation of a successful resource. A cache may store it only under narrow rules. Private error details should be marked no-store.

Retrying an unchanged 400 is pointless. Retry after you correct the request.

Codes people confuse with HTTP 400

422 is often a better fit for a semantically invalid but well-formed document. 415 is the wrong media type. 500 is your bug, not the client's.