The request succeeded. The body depends on the method. 200 belongs to the 2xx success class and is defined in RFC 9110.
Loading the workbench.
The request succeeded. The body depends on the method. The code is registered with IANA and defined in RFC 9110.
Success: the request was received, understood, and accepted. Every code from 200 to 299 shares that general meaning, so a client that does not recognise 200 must treat it like 200.
200 OK is the ordinary success answer. What the body contains depends on the method: a GET returns the resource, a HEAD returns the same headers with no body, and a POST returns the result of the action. Because it is so generic, APIs often return 200 even when something more specific fits, such as 201 for a newly created resource or 204 when there is nothing to send back. A 200 with an error message in the body is a common anti-pattern.
Nothing needs fixing on a genuine success. On the server, send an accurate Content-Type and a caching policy that matches the content, plus a validator such as ETag or Last-Modified so clients can revalidate cheaply. If the body actually describes a failure, change the status to the matching 4xx or 5xx code so monitoring, caches, and retries behave correctly. 200 responses to GET are cacheable by default when freshness information is present.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "a1b2c3"200 is cacheable by default under RFC 9110: a browser or CDN may store it and reuse it even without explicit freshness headers, using a heuristic lifetime. Send Cache-Control to say exactly how long.
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.
It works, but it hides failures from caches, proxies, monitoring, and client libraries that branch on the status code. Return the 4xx or 5xx code that matches the problem and describe it in the body.
A 200 is cacheable by default, but whether it is actually stored depends on Cache-Control, Expires, or a heuristic based on Last-Modified. Without any of those, caches behave inconsistently, so state your intent explicitly.
No. 200 is a success response, not an error.
Yes. RFC 9110 lists 200 as heuristically cacheable, so caches may store it without explicit headers. Use Cache-Control to control how long.
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.