422 Unprocessable Content: what it means and what to do
A 422 is the validation error with clean hands. Originally defined for WebDAV as Unprocessable Entity and renamed Unprocessable Content in RFC 9110, it means the server understood the content type, the syntax was correct, but it was unable to process the contained instructions. In everyday terms: the form was filled in neatly, and the answers were still wrong. Modern APIs use 422 as the standard answer for validation failures, such as an email address that is formatted correctly but already registered.
If you ran into this in a form or an app
- Read the message near the form. Unlike most codes, a 422 almost always arrives with specifics, the field and what is wrong with it. Fix exactly what it names.
- Check the flagged field's rules, not its spelling. The value passed the format checks but broke a rule: too short, already taken, out of range, or inconsistent with another field.
- Look for conflicts with existing data. Duplicate usernames, duplicate emails, and end dates before start dates are the usual 422 triggers in everyday apps.
If it is your API
- Use 422 for semantic validation, 400 for malformed requests. Broken JSON is a 400. Valid JSON with an impossible value is a 422. Keeping that line clean makes client error handling predictable.
- Return every failing field at once. Answering one error per round trip turns a simple correction into a frustrating loop. A field-by-field error list is the entire point of this code.
- Keep the error format stable. Clients build parsing around your 422 body. Changing its shape casually breaks their forms.
- Know your framework's default. Rails, Laravel, and FastAPI all emit 422 for validation failures out of the box, which is why the code dominates API work now.
Everyone: a 422 means the request arrived safely and was understood, then failed on content. The response body, not the code, holds the fix.
Common questions
What is the difference between 400 and 422? A 400 means the server could not process the request because it was malformed or structurally wrong. A 422 means the request was well formed and understood, but the data inside it failed validation rules.
Why did the name change from Unprocessable Entity? RFC 9110, the current HTTP standard, renamed it Unprocessable Content in 2022 to match the modern terminology used across the specification. The code, number, and meaning are unchanged, and older documentation using Entity means the same thing.
Related errors