Developer Tools

HTTP 200 OK

2xx Success. The request succeeded. The response body contains the requested resource or the result of the action.

Runs in your browser. Your files and text never leave your device - nothing is uploaded.

2xx Success

What it means

The request succeeded. The response body contains the requested resource or the result of the action.

PropertyDetail
Status class2xx Success
Defined inRFC 9110, Section 15.3.1
Cacheable by defaultYes. RFC 9110 lists it as heuristically cacheable, so a cache may reuse it without explicit freshness headers unless Cache-Control says otherwise. RFC 9110 asks servers to send an ETag and Last-Modified on a 200 to GET or HEAD when available, so caches can revalidate cheaply.
Who needs to actNo one, unless the content is wrong despite the 200.

What does HTTP 200 OK mean?

HTTP 200 OK means the request succeeded and the response carries the result. For a GET it is the requested page or data; for a POST it is the outcome of the action. It is the default success code, but a 200 only reports that the server handled the request, not that the content is correct or useful.

How 200 OK works

What a 200 contains depends on the method. RFC 9110 spells it out: GET returns the resource, HEAD returns the same headers with no body, POST returns the status or result of the action, PUT and DELETE return the status of the action, and OPTIONS returns the communication options. A 200 is expected to carry content; if there is nothing to send, 204 No Content is the more precise choice. The status matters to caches too. Because 200 is heuristically cacheable, a browser or CDN may reuse a response that has no Cache-Control header for a period it estimates itself, typically a fraction of the time since the Last-Modified date.

Example 200 request and response

GET /api/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
ETag: "a7f3c9"
Cache-Control: private, max-age=60

The ETag lets the client revalidate later with If-None-Match and receive a 304 instead of the full body, and Cache-Control replaces guesswork with an explicit 60-second lifetime.

When servers send 200 OK

  • A page, file or API resource that exists and was returned normally.
  • A form submission or API call whose result is described in the body.
  • Misleadingly, an error page or empty search page served with 200 because the application never set an error status.

How to handle 200 OK

If you consume an API

  • Do not assume a 200 means the operation did what you wanted; some APIs report errors inside a 200 body, so check the payload as well.
  • Keep the ETag or Last-Modified value if you will request the resource again.

If you run the site

  • Return a real error status, such as 404, 410 or 500, for error pages instead of a 200 with an error message.
  • Set Cache-Control deliberately, so browsers and CDNs do not apply their own heuristic freshness to dynamic pages.

200 and SEO

For Google, a 200 makes a page eligible for indexing but does not guarantee it. If a 200 page is empty or looks like an error message, Search Console reports it as a soft 404, which is one of the reasons it lists for pages that are not indexed. The usual culprits are removed products, expired listings and empty internal search results served with 200. Return 404 or 410 for pages that genuinely no longer exist.

Related status codes

  • 204 No Content: Success with nothing to send back, which avoids an empty 200 body.
  • 201 Created: Success that created something new, with a Location header pointing to it.
  • 304 Not Modified: Tells a client that its cached copy of an earlier 200 is still valid.
  • 206 Partial Content: Success for a byte range of the resource rather than all of it.

Frequently asked questions

Sources

Other 2xx Success codes

Reviewed by Raja Jahangir · Last reviewed: October 7, 2026