Skip to main content
snaptools
Categories json csv text encoding hash formatters converters generators
Guides Pricing Sign in
chain
#
HTTP 422 Unprocessable Entity
⌃⏎ run · ⎋ clear · / focus input
Meaning
send output to
no matches
Result appears here as you type
runs in your browser · nothing uploaded
// about this tool

HTTP 422 Unprocessable Entity Online

Updated 2026-10-24

HTTP 422 Unprocessable Entity means your request was parsed just fine (the JSON is valid, all required fields are present) but the data inside it fails a business or validation rule once the server actually checks it, like an invalid email format or a password that's too short.

Unlike 400, the fix here is about the DATA, not the structure: look at the specific field(s) called out in the response and correct the value, rather than the request format. A well-designed API returns a field-by-field breakdown of what failed, which is the fastest way to know exactly what to fix. For every other status code at once, use the full HTTP Status Codes reference.

// how to use

  1. 1 The code is already looked up below, with 422 pre-filled.
  2. 2 Type any other status code to look that one up instead.
  3. 3 Copy the result, or use the full HTTP Status Codes reference for every code at once.

// examples

The code itself
Input
422
Output
422 Unprocessable Entity: Client Error (4xx). The request is well-formed but semantically incorrect.
The code it's often confused with
Input
400
Output
400 Bad Request: the request itself is structurally malformed, before any validation runs.

// common uses

Handling form-validation errors from a JSON API Distinguishing a malformed request (400) from a validation failure (422) Designing a validation-error response shape for an API Checking what a status code in server logs actually means

// faq

Is anything uploaded to a server?
No. This is a local table lookup; nothing you type leaves the browser. 422 is unusual among the 4xx codes here in that a request can fail it even after auth, method, and resource-existence checks have all already passed.
What's a typical example of a 422?
Submitting a signup form with valid JSON and all required fields present, but the email field contains text that isn't a valid email address, or a password that's too short; the request is structurally fine, the data just fails a business rule.
How is 422 different from 400 Bad Request?
400 means the request itself can't even be parsed, due to broken JSON or wrong content type. 422 means parsing succeeded and the request is well-formed, but the DATA inside fails validation once the server actually looks at it.
Do all frameworks use 422 for validation errors?
Not universally; some REST APIs use 400 for validation failures too, since the distinction is somewhat a matter of convention (422 comes from WebDAV, RFC 4918). Check the specific API's documentation to know which one to expect.
What should a 422 response body contain?
Best practice is a structured list of which fields failed and why (e.g. email must be a valid email address), so the client can show the visitor exactly what to fix rather than a generic error.

// works with your data

HTTP 400 Bad Request HTTP 409 Conflict HTTP 404 Not Found HTTP Status Codes JSON Formatter Find & Replace

Use this via API

Get a free API key → 
curl -X POST https://thesnaptools.com/api/v1/tools/http-422 \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"422"}'