422 Unprocessable Entity

422 means 'I understood the request and the syntax is correct, but the semantics fail validation'. Distinguishes validation errors from malformed requests (400).

intermediate RFC 4918 §11.2 (originally WebDAV)

What the RFC says

The 422 Unprocessable Entity status code means the server understands the content type of the request entity (hence a 415 status code is inappropriate), and the syntax of the request entity is correct (hence a 400 status code is inappropriate) but was unable to process the contained instructions. (RFC 4918 §11.2) — RFC 4918 §11.2 (originally WebDAV)

Example

POST /api/users HTTP/1.1
Content-Type: application/json

{"email": "not-an-email", "age": -5}

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/problem+json

{
  "type": "https://example.com/probs/validation",
  "title": "Validation failed",
  "errors": [
    {"field": "email", "detail": "Invalid email format"},
    {"field": "age", "detail": "Must be >= 0"}
  ]
}

Real-world implementations

Rails defaults to 422 for ActiveRecord validation failures.
Django REST Framework returns 400 by default; many teams customize to 422.
RFC 7807 (Problem Details for HTTP) is the standard error envelope — pair with 422.

Common misuses (don't do this)

Using 400 when the body parsed fine but data is invalid — 422 is more specific.
Mixing 422 errors and 400 errors in same API — pick one convention and stick.
Returning 200 with `{success: false}` instead of 422 — breaks HTTP semantics, clients can't use status-code shortcuts.

Use cases

Form validation API design
Domain-rule violations (e.g. duplicate email)
Distinguishing parse errors from semantic errors
RFC 7807 error envelope adoption

Get the RFC reference for any HTTP response

httpwut takes a curl response and explains the status code + headers + the RFC sections you should actually read. Built for HTTP debugging that goes deeper than 'lol 500'.

Open httpwut