HTTP Status Codes
HTTP 422 Unprocessable Content
Unprocessable Content — the server understood the request but cannot apply its instructions
A 422 Unprocessable Content response indicates that the server successfully parsed the request syntax, understood the media type, and still rejected the payload because its meaning or data constraints were unacceptable. It is commonly used by APIs and form backends when the request body is well formed but semantically invalid. In practice, 422 often marks the boundary between transport-level parsing problems and application-level validation failures.
Visual summary
A quick reference view of how HTTP 422 works: A perfectly shaped box passing the outer gate, but failing an internal contents inspection.
What 422 Means
The shortest useful reading of this status code.
Unprocessable Content means the server understood the request but cannot apply its instructions.
This status falls into the 4xx class, indicating a client-side error outcome for the request.
Quick read
Unprocessable Content
the server understood the request but cannot apply its instructions
How to fix 422
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Read the validation errors in the response
Most APIs return a body that names the fields that failed. Inspect it to see exactly which values were rejected.
curl -i -X POST -H 'Content-Type: application/json' -d @payload.json https://example.com/apiFix the offending field values
Correct types, required fields, ranges, and business-rule violations so the payload satisfies the schema.
Validate the payload before sending
Check the request body against the API schema in the client so invalid data is caught before the request goes out.
Match the Content-Type to the body
Declaring application/json while sending form data makes the server misparse the payload. Ensure the header matches the actual format.
Technical Context
How this status behaves without turning the page into a repair guide.
Standard usage
A 422 sits one layer deeper than a 400. The server is able to parse the request and understands what fields or objects were sent, but it still cannot accept the content as valid for the requested action.
Technical nuance
That makes 422 especially common in JSON APIs, GraphQL-style mutations, and structured form submissions. It lets the application distinguish malformed input from well-formed input that fails validation, uniqueness checks, state rules, or domain constraints.
Related HTTP Codes
Nearby HTTP status codes help clarify how 422 differs inside the same response family.
422
Unprocessable Content
the server understood the request but cannot apply its instructions
400
Bad Request
the server cannot process the request because it is malformed
409
Conflict
Conflict
415
Unsupported Media Type
the request body format is not accepted here
Common Causes
JSON schema validation failed for the payload
A common condition that triggers a 422 response when the web server evaluates the transaction.
Required fields are present but semantically invalid
A common condition that triggers a 422 response when the web server evaluates the transaction.
Field values violate business rules or constraints
A common condition that triggers a 422 response when the web server evaluates the transaction.
Request contains conflicting or impossible data combinations
A common condition that triggers a 422 response when the web server evaluates the transaction.
Typical Scenarios
An API receives valid JSON but one field contains an impossible value
A form submits all required fields, yet a business rule rejects the combination
A backend parses the payload successfully but fails domain validation
What To Know
A 422 is usually tied to the exact payload submitted rather than to service availability. If one request body returns 422 while another succeeds, the differentiator is usually field content, state constraints, or validation logic for that specific operation.
Frequently Asked Questions
Common interpretation questions about HTTP 422.
A 400 usually means the server could not parse the request correctly. A 422 means the request was structurally valid, but the submitted content still failed application rules or validation.
It gives the API a clearer way to say that the payload was readable but unacceptable. That distinction is useful when clients need to separate malformed input from domain-level validation failures.
Yes. Valid JSON only means the payload can be parsed. The data inside it can still violate required formats, uniqueness rules, or state constraints and trigger a 422 response.