snaptools
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-07-26

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 — 422 is 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. The lookup runs entirely in your browser from a built-in table, so nothing you type leaves your machine.
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 — broken JSON, 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

Sort & Dedupe Lines Slug Generator Reverse Text Text Repeater Remove Duplicate Lines Whitespace Remover

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"}'
Esc
↑↓ navigate ↵ open Esc close