422 Unprocessable Content

The request is syntactically valid and understood, but the server cannot process the contained instructions due to semantic errors.

Defined in RFC 9110 §15.5.21

What 422 means

422 originated in WebDAV (RFC 4918) under the name "Unprocessable Entity" and has since been promoted into core HTTP by RFC 9110, which renamed it "Unprocessable Content" to match the specification's general shift from "entity" to "content" terminology. It means the request body was well formed — valid JSON, valid XML, whatever the content type demands — but the values inside it fail validation at the semantic or business-logic level rather than at the level of HTTP framing.

That distinction is exactly what separates 422 from 400 Bad Request. A 400 means the server could not even parse the request: truncated JSON, an unsupported content type, a missing required header. A 422 means parsing succeeded and the server understood exactly what was being asked, but a field is invalid, a value is out of range, or a business rule was violated. Many APIs blur this line and just use 400 for everything, which is imprecise but pragmatic, since most client code treats any 4xx as "fix your input" regardless of the exact number.

Framework conventions have made 422 a very consistent signal in a few ecosystems. Ruby on Rails is the clearest example: ActiveRecord validation failures return 422 by default with a body describing which fields failed and why, a convention that spread across the wider Ruby community. Laravel's form request validation does the same, returning 422 with a JSON errors object keyed by field name. FastAPI, built on Pydantic, automatically returns 422 whenever request body, query, or path parameters fail model validation, with a detailed array naming each failing field and constraint.

In practice, most APIs that follow these conventions return a JSON body with an errors or detail array, each entry naming the offending field, the constraint that failed, and a human-readable message, sometimes following a shared format like RFC 7807 Problem Details. Client-side form libraries and SDKs use this shape to map errors directly back onto the input fields that caused them, which is what makes 422 more actionable than a generic 400.

Common causes

A required field is missing from an otherwise well-formed JSON or XML request body.
A field fails type, format, or range validation, such as an invalid email address, a negative quantity, or a malformed date.
A business rule is violated even though every field is individually valid, such as an end date before a start date or a duplicate value where uniqueness is required.
A schema validator like Pydantic, Marshmallow, Joi, or class-validator rejects the payload against its defined model.
ActiveRecord, Eloquent, or a similar ORM raises validation errors when the framework attempts to persist the record.
The request is syntactically valid but references a foreign key or related resource that does not exist.

How to fix a 422

If you are the client (browser user or API caller)

Parse the response body for field-level error details and surface them directly to the end user or calling code.
Validate input client-side against the same rules the API enforces, to catch problems before submitting.
Consult the API documentation or OpenAPI schema for required fields, formats, and constraints.
Correct the specific offending field before retrying; resending the identical payload will fail again the same way.
Use the framework's validation error shape (Rails, Laravel, FastAPI conventions) to map errors back onto form fields automatically.

If you run the server

Return a structured error body naming the field, the failed constraint, and a human-readable message, rather than a bare 422 with no detail.
Keep client-facing validation hints (an OpenAPI or JSON Schema definition) in sync with the rules actually enforced server-side.
Use 400 for malformed or unparseable requests and reserve 422 specifically for semantic validation failures, so the distinction stays meaningful.
Adopt a consistent error format such as RFC 7807 Problem Details so every endpoint's errors can be parsed uniformly.
In frameworks like FastAPI, Rails, or Laravel, customize the default validation-error handler to return actionable messages instead of raw framework internals.

Example

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json

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

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{
  "errors": [
    {"field": "email", "message": "must be a valid email address"},
    {"field": "age", "message": "must be a positive integer"}
  ]
}

The JSON is well formed, but two fields fail semantic validation.

Try it live

Our free status responder returns a real HTTP 422 you can point tests, monitors or a browser at.

GET https://mcp.httpstatus.com/status/422