HTTP 200 OK
HTTP 200 OK is the standard success response. It means the request was received, understood, and completed — the server processed whatever the client asked and is returning the result. Despite being the simplest code to understand conceptually, 200 has specific semantics per HTTP method, carries real caching behavior, and is frequently misused in ways that break client tooling.
Quick reference
| Code | 200 |
|---|---|
| Name | OK |
| Category | 2xx Success |
| Specification | RFC 9110 §15.3.1 |
| IANA status | Assigned |
| Cacheable | Yes — cacheable by default with appropriate cache headers |
| Body | Expected and required (use 204 for success with no body) |
| In-depth guide | HTTP 200 usage and implementation guide → |
What HTTP 200 means
RFC 9110 defines 200 OK as the response when the request has succeeded and the meaning of success depends on the HTTP method used. This is a critical distinction that most documentation glosses over: 200 does not mean the same thing for every request type.
For GET, a 200 means the target resource exists and the response body contains its current representation. The server found what you asked for and is returning it.
For HEAD, a 200 means the same as GET but without the body. The response headers describe the resource as it would be returned for a GET request. This is used for checking resource existence and freshness without downloading the full content.
For POST, a 200 means the action described by the request was completed and the response body contains the result. This is appropriate when POST is used as a general-purpose action request — a login, a search, a computation — that does not create a new addressable resource. If a new resource was created, use 201 Created instead.
For PUT, a 200 means the target resource was updated and the response body contains the updated representation. If no body is needed after a PUT, 204 is more appropriate.
For DELETE, a 200 means the deletion was completed and the response body contains a description of the result. If nothing meaningful can be returned after deletion, 204 is more common.
When 200 is the wrong code
Returning 200 for a created resource
When a POST request creates a new resource, the correct response is 201 Created, not 200 OK. 201 includes a Location header pointing to the new resource, which allows clients to navigate directly to it. Returning 200 for resource creation is valid but loses the semantic signal and the Location header convention.
Returning 200 with an error in the body
One of the most common API antipatterns: returning 200 OK with a JSON body that contains "error": "Not found" or "success": false. This breaks HTTP monitoring tools, CDN error detection, retry middleware, and client libraries that branch on status codes. Always return the appropriate 4xx or 5xx code when the operation failed — even if your application framework makes it inconvenient.
Returning 200 for partial content
When responding to a range request (Range header), the correct response is 206 Partial Content, not 200. Returning 200 for a partial response tells the client it received the full resource, which breaks range-aware clients like video players and download managers that rely on byte ranges.
Returning 200 with no body
A 200 response is expected to include a body. If the action succeeded but there is nothing meaningful to return, use 204 No Content. Some clients handle 200 with empty body correctly, but it is technically non-conforming and wastes client-side parsing cycles on an empty parse.
Caching behavior
200 responses are cacheable by default. Without explicit Cache-Control headers, GET and HEAD 200 responses may be stored and reused by browsers and intermediate caches (CDNs, proxies). POST 200 responses are not cached by default.
To control caching explicitly: use Cache-Control: no-store to prevent caching entirely, Cache-Control: no-cache to require revalidation before serving from cache, or Cache-Control: max-age=3600 to allow caching for a specific duration. Without these headers on a GET 200, browsers apply heuristic caching based on the Last-Modified or Date header — typically caching for a fraction of the resource's apparent age.
CDNs and reverse proxies cache 200 responses aggressively. If an endpoint returns sensitive or user-specific content, ensure Cache-Control: private or no-store is set. A 200 response without these headers on a shared cache will serve one user's content to another.
200 in API design
REST API design uses 200 as the default success code for retrieval and general action operations. The convention is to return 200 for GET requests that find the resource, POST requests that perform an action without creating a resource, and PUT or PATCH requests that update an existing resource.
GraphQL APIs commonly return 200 for all responses — including partial errors — because errors in GraphQL are application-layer events, not HTTP failures. The errors array in the response body conveys error details. This is a deliberate design choice for GraphQL's transport model and not a misuse of 200 in that context.
gRPC-Web also tunnels all responses through HTTP 200 with a Content-Type: application/grpc-web envelope. The actual gRPC status code lives in the response body or trailers. If you see a 200 from a gRPC endpoint, look inside the envelope for the real status.
200 vs related 2xx codes
| Code | Name | Use when | Body expected |
|---|---|---|---|
| 200 | OK | Request succeeded, result is in the body | Yes |
| 201 | Created | POST created a new resource; Location header points to it | Optional |
| 202 | Accepted | Request accepted but processing is async and not yet complete | Optional (status URL recommended) |
| 204 | No Content | Request succeeded but there is nothing to return | No |
| 206 | Partial Content | Responding to a Range request with a subset of the resource | Yes (the requested range) |
FAQ
What does HTTP 200 mean?
HTTP 200 OK means the request was received, understood, and completed successfully. The response body contains the representation of the requested resource (for GET) or the result of the action (for POST). It is the most common HTTP status code in normal web traffic.
When should a server return 200 instead of 201?
Return 201 Created when a POST request results in a new resource being created. Return 200 when a POST performs an action that succeeds but does not create a new identifiable resource — for example, a login endpoint, a search query, or a data transformation request.
Why would a 200 response have an empty body?
A 200 response should contain a body. If you intend to return success with no body, the correct code is 204 No Content. A 200 with an empty body is technically valid but may cause issues in clients that expect content to parse. Use 204 for no-body success responses.
Can a 200 response indicate an application-level error?
Yes — and this is a widespread antipattern. Some APIs return 200 with a JSON body containing an error field. This breaks HTTP client libraries, monitoring tools, and retry logic. Always use the correct HTTP error code to signal failure at the protocol layer.
Is HTTP 200 cacheable?
Yes. 200 responses to GET and HEAD requests are cacheable by default. Without explicit Cache-Control headers, browsers and intermediaries may cache them using heuristics. Set Cache-Control explicitly to control this behavior for your endpoints.
Related resources
On this site: HTTP 200 usage and implementation guide · HTTP 201 Created · HTTP 202 Accepted · HTTP 204 No Content · HTTP 206 Partial Content · All 2xx success codes
Standards: RFC 9110 §15.3.1 · IANA HTTP Status Code Registry · MDN Web Docs: 200