HTTP 400 Bad Request

What HTTP 400 means

HTTP 400 Bad Request means the server read the request and rejected it as invalid before doing any real work. It is the catch-all client error: malformed syntax, invalid parameters, corrupted cookies or headers the server refuses to process.

Unlike 401 or 403, a 400 says nothing about permissions — the request was broken on arrival. APIs often attach a JSON body explaining exactly which field failed validation.

Common causes of 400 errors

• Malformed JSON or XML in the request body (trailing commas, wrong quotes, truncated payload).
• Missing or invalid query parameters, or values failing server-side validation.
• Corrupted or oversized cookies — the classic cause of persistent 400s on big sites for one user.
• Wrong Content-Type header, so the server parses the body as the wrong format.
• URL-encoding mistakes: unescaped spaces, quotes or non-ASCII characters in the query string.

How to fix it as a user

• Reload the page; if the 400 persists, clear cookies for that site — corrupted cookies are the most common cause.
• Check the URL for typos or characters that were mangled when copying and pasting.
• Try an incognito window to rule out extensions rewriting requests.

How to fix it as a developer

• Validate JSON payloads before sending; log the exact request body the server received.
• Return a response body that names the invalid field — a bare 400 wastes everyone's debugging time.
• Check server limits on header and cookie size (nginx large_client_header_buffers, etc.).
• Use 422 for well-formed but semantically invalid input if your API distinguishes the two.

Example response

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

{"error":"validation_failed","field":"email","message":"not a valid address"}

FAQ