400 vs 422: Bad Request vs Unprocessable Content
400 and 422 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 400 — Bad Request | HTTP 422 — Unprocessable Content |
|---|---|---|
| Definition | The server received a request it cannot parse or understand. This is a client-side error — the request itself is malformed. | The server understands the Content-Type and the request is well-formed, but cannot process it due to semantic errors. Common in REST API validation failures. |
| Plain-language summary | The server cannot parse or process the request because it is malformed. The error is always on the client side — the request itself is structurally invalid. Common causes include invalid JSON, missing required headers, malformed URL encoding, or a content type mismatch. | The request body is syntactically valid (it parsed successfully) but semantically invalid — the content violates business rules or data constraints. The most common use is REST API field validation failures. |
| When to use | Return 400 when the request is syntactically invalid or unparseable. Use 422 when the request is syntactically valid but semantically invalid (valid JSON that violates business rules). Use 401 for missing/invalid authentication, 403 for insufficient permissions, 404 for unknown resources. | Return 422 when the body was parsed correctly but failed validation: required field present but empty, value out of allowed range, date in the past when future is required, or custom business rule violation. Use 400 for parsing failures (malformed JSON, wrong Content-Type). Use 409 for conflicts with existing resource state. |
| Client behavior | Do not retry automatically — the same malformed request will receive the same 400. Fix the request format and retry. API clients should surface the error to the developer with the response body details. | Do not auto-retry. Fix the payload based on the validation errors in the response body. Implement client-side validation to prevent 422s before the request is sent. |
| Caching behavior | Not cached. Error responses are generally not stored. | Not cached. |
| SEO / crawler impact | Search crawlers interpret 400 (client-errors) for indexation and link equity accordingly. | Search crawlers interpret 422 (client-errors) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 400 expect Bad Request semantics. | API clients branching on 422 expect Unprocessable Content semantics. |
| Safe to retry? | Only after fixing the underlying cause | Only after fixing the underlying cause |
Common real-world scenarios
When you see HTTP 400
In API logs, 400s indicate client-side integration bugs. Sudden spikes in 400s often correlate with: a bad client deployment sending malformed payloads, a frontend change that broke the request format, or an API schema change that old clients have not adopted. Monitor 400 rates per endpoint to detect client bugs early.
When you see HTTP 422
In form-heavy APIs, high 422 rates indicate: poor client-side validation that lets invalid data reach the server, mismatch between frontend and backend validation rules, or an API schema change that old clients have not adopted.
Decision rule
Use 400 when the response should communicate bad request behavior; use 422 when unprocessable content is the accurate protocol signal.
A frequent mistake is swapping 400 and 422 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 400 when the correct protocol signal is Bad Request. Use 422 when the correct signal is Unprocessable Content. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 400 and 422?
400 communicates Bad Request, while 422 communicates Unprocessable Content. Choosing the right one keeps clients and intermediaries predictable.
Do 400 and 422 have SEO or caching impact?
Yes. Search engines and caches interpret status classes differently. Use each code according to its semantics to avoid accidental indexing, stale responses, or crawl inefficiency.
Can APIs safely return 400 instead of 422?
Only when it matches contract semantics. API clients often branch logic by exact code, so swapping them can break retries, auth handling, or user-facing errors.
Full guides
HTTP 400 Bad Request — full guide · HTTP 422 Unprocessable Content — full guide · All comparisons · HTTP 400 status reference · HTTP 422 status reference