422 Unprocessable Entity 4xx

What does 422 mean?

A 422 Unprocessable Entity response means the server understood the request and successfully parsed its content (the JSON/XML/form data is syntactically valid), but the data itself fails validation in some way — a value is the wrong format, a required combination of fields is missing, or a business rule rejects it.

This is the key distinction from 400: a 400 often means the request couldn't even be parsed correctly (broken syntax). A 422 means parsing succeeded — the server fully understood what you're asking — but the content doesn't meet the requirements for that operation to succeed.

422 originated in WebDAV (an extension to HTTP for web-based file authoring) but has been widely adopted far beyond its original context, becoming the de facto standard for validation errors in REST APIs.

How a 422 behaves

• It typically carries a detailed body — this is one of the most body-dependent status codes in practice, since the whole point is communicating which fields failed validation and why
• It's not cacheable — validation results are specific to the submitted data
• Fixing it requires changing the data, not just retrying — similar to 400, but the issue is with values/content rather than structure
• It often maps directly to form validation — many APIs return a 422 with a structured object listing each invalid field and its specific error message, designed to be displayed directly next to form fields in a UI

Common causes

If you're building the API or website:

• A field value doesn't match the expected format (e.g., a string that isn't a valid email address, a date string that can't be parsed)
• A required field is present but empty, or a field that should be unique already exists (though some APIs use 409 Conflict for uniqueness violations instead)
• Cross-field validation fails — e.g., an "end date" that's before the "start date," even though both individual fields are valid on their own
• A value is outside an acceptable range (a percentage over 100, a negative quantity for a physical product)

If you're calling an API:

• You're sending a value in the wrong format — a date as 03/15/2026 when the API expects ISO 8601 (2026-03-15)
• A field that's required for this specific operation is missing, even though it might be optional for other operations on the same resource
• An enum/choice field contains a value that isn't in the accepted list (e.g., sending status: "done" when the API only accepts "pending", "active", "completed")
• Numeric or string length constraints are violated — too long, too short, too big, too small

If you're a website visitor:

• A form is rejecting your input due to a validation rule — most commonly surfaces as inline error messages next to specific fields
• You've entered data in a format the form doesn't expect (e.g., a phone number with extra characters the validator doesn't strip)

How to fix it

As an API/website builder:

• Return a structured error body that maps validation failures to specific fields — something like { "errors": { "email": ["must be a valid email address"] } } — this is far more useful to API consumers than a generic message
• Document validation rules clearly: required fields, formats, allowed ranges, enum values
• Be consistent about when you use 422 vs 400 vs 409 across your API — inconsistency here is one of the most common sources of confusion for API consumers
• For forms, surface 422 validation errors inline next to the relevant fields rather than as a generic page-level error

As an API consumer:

• Read the response body carefully — 422 responses are usually the most informative error responses an API will give you, often listing exactly which fields are wrong and why
• Cross-check field formats against the API's documentation, especially for dates, enums, and numeric ranges
• If cross-field validation is failing (e.g., date ranges), check the relationship between fields, not just each field individually

As a website visitor:

• Look for inline error messages near specific form fields — 422-style validation errors are usually displayed this way
• Double-check formats for dates, phone numbers, and other structured fields
• If a field has a character limit, check whether you're over it — this is a frequent, easy-to-miss cause

400 vs 422

A useful mental model: if you ran the request body through a JSON/XML parser and it would fail to parse → that's 400 territory. If it parses fine but a human reviewing the values would say "wait, that date doesn't make sense" or "that's not a valid email" → that's 422 territory.

Real-world examples

Many modern REST APIs — especially those built with frameworks that have built-in validation layers — use 422 as the standard response for validation failures on POST/PUT/PATCH requests, returning a structured JSON object with per-field error messages designed to be consumed directly by frontend forms. This pattern has become common enough that many frontend form libraries have built-in support for parsing 422-style validation error responses and mapping them to form field errors automatically.

SEO implications

422 is almost exclusively relevant to form submissions and API requests (POST/PUT/PATCH), not to regular page navigation (GET requests) — so it has essentially no direct SEO implications for content pages. It's purely an application/API-layer concern.

FAQ

What's the difference between 400 and 422?

400 means the request itself couldn't be properly parsed or understood — broken syntax, wrong content type, missing required structure. 422 means the request was parsed successfully, but the data within it fails validation rules — wrong format, out of range, failed business logic checks.

Why would an API use 422 instead of just 400 for everything?

Using 422 specifically for validation errors lets API consumers programmatically distinguish "your request format is fundamentally broken" (400 — likely a bug in the client code) from "your request format is fine, but this particular data doesn't pass validation" (422 — likely something the end user needs to correct, like a form error).

Is 422 used outside of REST APIs?

422 originated in WebDAV, a protocol extension for collaborative document editing over HTTP. While that's a niche use case today, the concept — "well-formed but semantically invalid" — generalized so well that 422 became one of the most widely adopted status codes for API validation, far beyond its original WebDAV context.

My API returns 409 for some validation issues and 422 for others — is that normal?

Yes, this is common. 409 Conflict is often used specifically for uniqueness or state conflicts (e.g., "a user with this email already exists," or "this resource was modified by someone else"), while 422 is used for format/value validation issues (e.g., "this field must be a positive number"). Different APIs draw this line differently, so checking each API's specific conventions is worthwhile.

Can a single request return multiple 422 errors at once?

Yes, and this is considered good practice — rather than returning a 422 for the first validation failure found and requiring the client to fix it and resubmit (potentially hitting a second validation error), well-designed APIs validate the entire request and return all validation errors in a single 422 response.

Fun fact

422 is one of the few status codes whose origin (WebDAV, RFC 4918) is in a completely different protocol extension than where it's now most commonly used (general-purpose REST API validation) — a good example of how useful HTTP semantics tend to get adopted far beyond their original, narrow purpose.