Is 422 the same as 400 Bad Request?

No, and the gap between them is the entire diagnosis. A 400 means the server couldn't even parse your request — broken JSON, a truncated body, bytes the parser choked on. A 422 (RFC 9110 §15.5.21) means the parse succeeded and the syntax was valid; the server understood exactly what you sent and rejected it on the contents. Your JSON is perfect. The problem is that `email` isn't a valid address, or `quantity` is negative, or you referenced an order that doesn't exist. 400 is 'I can't read this.' 422 is 'I read it, and it's wrong.'

How is 422 different from 415 Unsupported Media Type?

They fail at different stages. 415 rejects the format before the server reads the body — the Content-Type wasn't one it accepts on that route, so it never got to your data. 422 means the format was accepted and the body was read and parsed successfully; it only failed once the server checked the contents against its rules. If you're getting 415, fix your Content-Type header. If you're getting 422, your header was fine and the payload itself is the problem.

Why does Ruby on Rails return 422 for a CSRF token error?

Because Rails treats an invalid or missing anti-forgery token as an unprocessable request rather than an authentication failure. When `protect_from_forgery` fires, Rails raises `InvalidAuthenticityToken` and answers 422 — not 401 or 403. This surprises people building a SPA or a fetch call against a Rails backend: every field validates, but the 422 has nothing to do with your data. The stale or absent CSRF token is the whole story. If your 422 appears on a form POST with no field errors in the body, check the token before you check anything else.

Views: 91

422 Unprocessable Content: Fix Failed Validation

422 Unprocessable Content means your body parsed but failed validation. Read the field errors, tell it from 400 and 415. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

A POST, PUT, or PATCH comes back 422 Unprocessable Content. The endpoint exists, your auth works, your Content-Type is correct, and the JSON is valid — you can paste it into a linter and it parses clean. The server read your body, understood it, and rejected it anyway. Something in the contents failed a rule.

Symptoms

A write request returns 422 while a GET on the same resource returns 200.
The response body contains a list of field errors — "email": ["is invalid"], "errors": {...} — not a stack trace.
The exact same payload works with one value changed, which means the format is fine and a specific field is the culprit.
On a Rails backend, a form POST returns 422 with no field errors in the body — a CSRF token problem wearing a validation status code.

What 422 Actually Means

RFC 9110 (§15.5.21) defines 422 as the server understanding “the content type of the request content” and finding “the syntax of the request content is correct” but being “unable to process the contained instructions.” Read the three clauses in order: the media type was accepted, the body parsed, and only then did processing fail. That sequence is the diagnosis. A 422 is proof that your request got all the way to the application’s validation layer before it was turned away.

The code has a confusing history worth knowing. It was born in WebDAV (RFC 4918 §11.2) as “Unprocessable Entity,” which is why older frameworks, MDN’s old docs, and half the Stack Overflow answers still call it that. RFC 9110 promoted it into core HTTP semantics and renamed it “Unprocessable Content.” Same code, same meaning — the internet just spent fifteen years arguing about the noun.

The practical upshot: 422 is the code frameworks reach for when your input is well-formed but breaks a business or validation rule. Laravel returns 422 automatically when a ValidationException meets a request that expects JSON. Django REST Framework and FastAPI do the same for schema violations. Rails uses 422 Unprocessable Entity as the idiomatic response for a failed save. When you see 422, the server isn’t broken and neither is your syntax. Your data just didn’t pass the rules.

Top 3 Causes

Field-level validation failure - The overwhelming favorite. A required field is missing, a string is too long, a number is out of range, an email doesn’t match the format, an enum value isn’t on the allowed list. The framework’s validator (Laravel’s validate(), a DRF serializer, a Pydantic model, an ActiveModel validation) checks your parsed body against a schema and rejects the first thing that doesn’t fit. The good news: the response body almost always names the exact field and the exact rule it broke. Read it before you do anything else.
A semantic or business-rule violation - The syntax is fine and every field is individually valid, but the request doesn’t make sense against the current state or the domain rules. You referenced a customer_id that doesn’t exist. You set a start_date after the end_date. You ordered a quantity larger than the stock. Two mutually exclusive fields were both provided. Nothing is malformed — the combination is just impossible, and the server refuses to act on it.
A stale or missing CSRF/anti-forgery token (Rails and friends) - This one masquerades as a data problem. Frameworks that treat forgery protection as a processability check — Rails is the notable one — answer 422 when the token is wrong or absent. Your fields are flawless; the request is rejected because the anti-forgery token expired, wasn’t sent, or wasn’t refreshed after login. People wiring up a JavaScript client against a server-rendered backend hit this constantly and waste an hour auditing field values that were never the problem.

Diagnose with DechoNet

HTTP Check to confirm the route itself is healthy and see the exact status line the endpoint returns to a clean request. A 422 is tied to one specific write with one specific body, so a neutral check usually comes back 200 or 405 — and that split is the point. If the endpoint answers normally to a plain request, the 422 lives in your payload versus the server’s rules, not in a broken deployment. Once you’ve confirmed the route is up, the real answer is in the 422 response body: read the field-error list the server sent back.

Resolution Checklist

Read the response body first. A 422 almost always carries a structured list of what failed — field names and rule names. This is the single fastest path to the fix, and most people skip straight past it to guess at their JSON.
Match every field against the API’s documented schema: required vs optional, expected types (a string "5" where the server wants a number 5 is a classic 422), allowed enum values, min/max lengths, and format rules like email or date.
Check for semantic conflicts the schema won’t catch — a referenced ID that doesn’t exist, a date range that’s backwards, a value that violates a uniqueness or state rule. These pass field validation and fail the business logic.
If you’re on a Rails (or similar) backend and the 422 body has no field errors, suspect the CSRF token. Send a valid anti-forgery token, or if it’s a token-authenticated API, confirm forgery protection is configured for API requests rather than form sessions.
Confirm it isn’t a 400 in disguise. If the server can’t even parse your body — malformed JSON, wrong bracket, truncated payload — you’d get 400, not 422. A 422 proves the parse succeeded, so stop debugging your syntax.
Fix the offending field or rule, re-send, and confirm the endpoint returns 2xx.

When to Escalate

If legitimate clients are hitting 422 on data you believe is valid, the mismatch is between the client’s assumptions and the server’s validation rules — compare the request against the schema the API actually enforces, not the one the docs describe. Documented and enforced schemas drift apart more often than anyone admits.
If a 422 appears with an empty or unhelpful body — no field errors, no message — that’s a server-side bug, not a client one. An API that rejects input on validation grounds but won’t say which field failed is a support ticket generator; the fix is to make the 422 payload list the specific failures, as RFC 9110 intends.