422 Unprocessable Content
The server understands the content type and syntax, but cannot process instructions.
Usually happens because:
- ☑ Input fields validation failing (e.g.,
- ☑ Semantic errors in requests, such
🔍 Quick Checklist:
Meaning
The HTTP 422 Unprocessable Content client error status code (formerly Unprocessable Entity) indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but was unable to process the contained instructions (e.g. form input validation errors).
Root Causes
- Input fields validation failing (e.g., missing required fields, or fields not matching regex).
- Semantic errors in requests, such as attempting to purchase an out-of-stock item.
| Cause | Frequency |
|---|---|
| Input fields validation failing (e.g., | ⭐⭐⭐⭐⭐ |
| Semantic errors in requests, such | ⭐⭐⭐⭐ |
Common Mistakes
- Using 400 Bad Request for validation errors (400 is for syntax corruption; 422 is for semantic/validation errors).
- Omitting error field details in the response body.
How to Fix
Framework-Specific Examples
Using express-validator to check fields and return 422 on failures.
const { body, validationResult } = require('express-validator');
app.post('/user', body('email').isEmail(), (req, res) => {
const errors = validationResult(req);
if (!errors.isEmpty()) {
return res.status(422).json({ errors: errors.array() });
}
});Server Configuration Examples
Nginx passes status 422 downstream to application server.
# Handled by appPrevention
- Implement validation schemas (Zod, Joi) across all route endpoints.
- Synchronize validation rules between frontend forms and backend models.
Frequently Asked Questions (FAQ)
Q: What is the difference between 400 and 422?
Use 400 Bad Request when the server cannot parse the request (e.g. malformed JSON). Use 422 Unprocessable Content when the syntax is correct but the values fail semantic validation (e.g. invalid email format).
Q: What is the new name of 422?
In newer HTTP specifications, the name has been changed from '422 Unprocessable Entity' to '422 Unprocessable Content'.
Q: Is 422 cacheable?
No. The 422 status code is not cacheable by default.
Q: Should my frontend check for 422 explicitly?
Yes. Frontend fetch handlers should intercept 422, extract the error details array, and display inline validation messages next to the corresponding form inputs.