Why is 422 sometimes called Unprocessable Entity?
WebDAV (RFC 4918) originally named it Unprocessable Entity. RFC 9110 adopted the code for general HTTP in 2022 and renamed it Unprocessable Content.
The syntax is fine but the content fails validation. Common in JSON APIs. 422 belongs to the 4xx client error class and is defined in RFC 9110.
Loading the workbench.
The syntax is fine but the content fails validation. Common in JSON APIs. The code is registered with IANA and defined in RFC 9110.
Client error: the request has a problem, so it cannot be fulfilled as sent. Every code from 400 to 499 shares that general meaning, so a client that does not recognise 422 must treat it like 400.
422 Unprocessable Content means the server understood the request and its syntax is valid, but the content cannot be processed as given. It is the usual answer for validation failures in JSON APIs: a required field is empty, a date is in the past, an email address is malformed, or a value is out of range. Frameworks such as Rails, Laravel, and FastAPI return it by default for validation errors.
Servers should return a body that lists each failing field and why, preferably in a consistent format such as application/problem+json with per-field errors. Clients should display those messages next to the relevant inputs, fix the data, and resend; retrying unchanged will fail again. Use 400 instead when the body cannot be parsed at all, such as invalid JSON.
HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json
Content-Length: 214422 is not cacheable by default: a browser or CDN stores it only when Cache-Control or Expires explicitly allows it.
To inspect a real one without sending it anywhere:
curl -i.Browse every code on the HTTP status codes page.
Elsewhere in 2http: Header decoder, Cookie decoder, Cache-Control decoder, CORS checker, User-agent parser, and all eleven lanes on the 2http home page. Part of the 2suite.io privacy-first ecosystem.
WebDAV (RFC 4918) originally named it Unprocessable Entity. RFC 9110 adopted the code for general HTTP in 2022 and renamed it Unprocessable Content.
Many APIs use 422 for well-formed but invalid data and 400 for unparseable requests. Both are acceptable if your API documents and applies the choice consistently.
Yes. 422 is a client error response: the problem is in the request, so repeating it unchanged will usually fail again.
No. Caches store a 422 only when Cache-Control or Expires explicitly allows it.
You do not have to take our word that your headers stay here. Developer tools show every request a page makes, so you can watch this page work and confirm that nothing is sent. The check takes under a minute.
F12, or Cmd+Option+I on a Mac, and select the Network tab.Only two things can add a line to that log, and neither carries your headers. Submitting the feedback form sends the vote and comment you typed. Typing characters in a script the page has not displayed yet, such as Cyrillic or Greek, can make the browser fetch the matching font file, and that request names only the font.
2http never sends a request on your behalf: the request builder writes code for you to run, and the meta inspector reads source you paste instead of fetching a URL. The production site also sends a Content-Security-Policy header that tells your browser to refuse connections to anywhere except this site and the anonymous analytics endpoint.