HTTP 400 Bad Request

The server could not understand the request — malformed JSON, a missing required field, or a parameter of the wrong type.

Defined in RFC 9110 §15.5.1 — 400 Bad Request · MDN reference

Where you meet HTTP 400 in production

Malformed JSON, a query parameter of the wrong type, a missing required field, a payload the parser cannot make sense of at all.

Why you would test it

The baseline negative test. It is also the code most often used where 422 would be more accurate, so check which one your API actually sends.

What your client should do about a 400

Never retry a 400 unchanged — the request is wrong and will be wrong the second time. Surface the server's error detail rather than a generic failure message; the whole value of a 400 is that it says what it did not understand.

400 versus the codes it gets confused with

Endpoints that return 400

105 endpoints in this playground answer with 400. Every one is free, needs no signup, and can be called from the browser or with curl.

…and 80 more endpoints across the catalog.

Questions about HTTP 400

Is 400 a catch-all for client errors?
It is often used that way, but a specific code — 401, 403, 404, 409, 422 — tells the caller far more, and lets their client behave differently for each.
Should a 400 have a body?
Yes. A 400 with no explanation makes the caller guess, and guessing is how retries begin.

Other client error codes

All HTTP status codes · All 39 mock REST APIs · Getting started guide

Last updated