What is the difference between 400 and 422?
Use 400 when the request cannot be parsed, such as invalid JSON. Use 422 when the syntax is fine but the content fails validation, such as an email field without an at sign.
The request is malformed: bad syntax, invalid framing, or an unreadable body. 400 belongs to the 4xx client error class and is defined in RFC 9110.
Loading the workbench.
The request is malformed: bad syntax, invalid framing, or an unreadable body. 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 400 must treat it like 400.
400 Bad Request is the server refusing a request it considers malformed: broken JSON, missing required fields in some APIs, invalid query syntax, illegal characters in headers, conflicting Content-Length values, or an oversized cookie on some servers. Because it is the generic client error, many frameworks use it for any validation failure. Web servers such as nginx also send 400 when a request is not valid HTTP at all, for example plain HTTP sent to an HTTPS port.
Read the response body first; good APIs say exactly which field or header was wrong. Validate JSON before sending and check the Content-Type matches the body. Rebuilding the request in the 2http Request builder is a quick way to check quoting. Servers should return a precise error description, ideally as application/problem+json, and use 422 for well-formed content that fails business validation and 431 for oversized headers.
HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Content-Length: 112400 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.
Use 400 when the request cannot be parsed, such as invalid JSON. Use 422 when the syntax is fine but the content fails validation, such as an email field without an at sign.
Large or corrupted cookies are a common cause; some servers answer 400 instead of 431 when the Cookie header is too big. Clearing the site cookies often fixes it.
Yes. 400 is a client error response: the problem is in the request, so repeating it unchanged will usually fail again.
No. Caches store a 400 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.