Quick answer
HTTP 422 Unprocessable Entity means the request was well-formed (valid JSON) but failed semantic validation — a field has an invalid value or a business rule was violated.
What HTTP 422 means
422 Unprocessable Entity is widely used by JSON APIs to report validation failures. The server understood the request and the JSON parsed fine, but the data itself is invalid — an email in the wrong format, a value out of range, or a missing relationship. The response typically lists the specific field errors.
Common causes
- A field fails validation (invalid email, too short, out of range)
- A required field is null or empty
- A value violates a business rule (e.g. end date before start date)
- A referenced resource does not exist
Example JSON error response
{
"error": "Unprocessable Entity",
"message": "Validation failed",
"status": 422,
"errors": [
{ "field": "email", "message": "is not a valid email address" },
{ "field": "age", "message": "must be 18 or older" }
]
}Raw HTTP response
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/jsonHow to troubleshoot HTTP 422
- ✓ Read the
errorsarray in the response body for field-level details - ✓ Fix each field that failed validation
- ✓ Check value ranges, formats, and required relationships
- ✓ Confirm the JSON itself is valid first (otherwise you get a 400)
- ✓ Re-submit once all listed fields are corrected
400 vs 422 — what's the difference?
400 Bad Request means the server could not even parse the request — for a JSON API, the body isn't valid JSON. 422 Unprocessable Entity means the JSON parsed fine but the data failed validation. If the parser chokes, it's 400; if it reads the data but rejects its values, it's 422.
Surfacing 422 errors in client code
The value of a 422 is the structured errors array — map it straight onto your form fields instead of showing one generic message. That turns a rejected submit into precise, per-field feedback:
const res = await fetch('/api/users', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(form),
});
if (res.status === 422) {
const { errors } = await res.json();
for (const { field, message } of errors) {
showFieldError(field, message); // e.g. email → "is not a valid email"
}
return;
}Which frameworks return 422?
422 is the de-facto validation status across modern frameworks, even though it began in WebDAV:
| Framework | Validation behavior |
|---|---|
| Rails | Returns 422 by default for failed model validations |
| Laravel (PHP) | Form-request validation failures return 422 with an errors object |
| FastAPI (Python) | Pydantic validation failures return 422 automatically |
| Express (Node.js) | Manual — return res.status(422).json({ errors }) (e.g. with express-validator) |
A consistent, machine-readable errors shape matters more than the exact status — but 422 is the clearest signal of "valid request, invalid data."
Frequently Asked Questions
What is the difference between 400 and 422?
400 means the request is malformed and cannot be parsed (e.g. invalid JSON). 422 means the JSON is valid but fails validation — a field has a bad value or breaks a rule. Use 400 for unparseable requests and 422 for valid-but-rejected data.
How do I fix a 422 error?
Read the validation errors in the response body — most APIs return an errors array naming each failing field. Correct those fields (formats, ranges, required values) and resubmit.
Is 422 part of the HTTP standard?
422 originated in WebDAV (RFC 4918) and is now widely adopted by REST/JSON APIs for validation errors. It is well supported by frameworks and clients even though it is not in the original core HTTP spec.
Should validation errors use 400 or 422?
Both are seen in the wild. The cleaner convention: use 400 when the body can't be parsed at all (malformed JSON), and 422 when the JSON is valid but the data fails validation. Frameworks like Rails, Laravel, and FastAPI default to 422 for validation, so it's the more precise and widely-expected choice.
What should a 422 response body contain?
A machine-readable list of field-level errors — typically an errors array (or object) where each entry names the failing field and a human-readable message. This lets clients map each error onto the relevant form field instead of showing one generic "validation failed" message.
The server says your request was wrong
Most 4xx bodies carry a JSON error object explaining which field it objected to. Format it and read the detail — nothing leaves your browser.