HTTP Status Codes
HTTP 200 OK (Success)
OK (Success) — the request succeeded and the server returned the expected response
200 OK is the status code for a succeeded request: the server processed it, and the meaning of the response content follows the request method. For GET the content is a representation of the target resource, for HEAD the same without transferring the data, for POST the status of or results obtained from the action, and for PUT or DELETE the status of the action. A 200 response is expected to carry content unless the message framing marks it as zero length, and when success should send nothing the server responds 204 instead. 200 responses are heuristically cacheable.
Visual summary
A quick reference view of how HTTP 200 works: A successful transfer of the requested resource.
What 200 Means
The shortest useful reading of this status code.
OK (Success) means the request succeeded and the server returned the expected response.
This status falls into the 2xx class, indicating a successful outcome for the request.
Quick read
OK (Success)
the request succeeded and the server returned the expected response
Technical Context
How this status behaves without turning the page into a repair guide.
Standard usage
The 200 (OK) status code indicates that the request has succeeded, and the content sent in the response depends on the method: for GET it is a representation of the target resource, for HEAD the same without transferring the representation data, for POST the status of or results obtained from the action, and for PUT and DELETE the status of the action.
Technical nuance
A 200 response is expected to contain message content unless the framing explicitly marks it as zero length. The exception is HEAD, defined as identical to GET except that the server must not send content. When the request itself indicates a preference for no content upon success, the server's response is 204 instead.
Implementation detail
In 200 responses to GET or HEAD, an origin server should send any available validator fields, preferring a strong entity tag together with a Last-Modified date. Those validators are what let later conditional requests resolve to 304 instead of transferring the representation again.
Architecture
A 200 response is heuristically cacheable unless the method or explicit cache controls say otherwise. The status also says nothing about application semantics: a body containing {"error": true} inside a 200 is a successful HTTP exchange with a failed business outcome, which is why API clients inspect the payload and not just the status.
Related HTTP Codes
Nearby HTTP status codes help clarify how 200 differs inside the same response family.
200
OK (Success)
the request succeeded and the server returned the expected response
201
Created
the request was successful and a new resource was created
204
No Content
the request was successful but there is no content to return
206
HTTP 206 Partial Content
the server is sending a requested range
Common Causes
A GET or HEAD request succeeded and the server returns a representation of the target resource, with HEAD leaving out the data itself
A common condition that triggers a 200 response when the web server evaluates the transaction.
A POST, PUT, or DELETE action completed and the response reports the status of, or results obtained from, the action
A common condition that triggers a 200 response when the web server evaluates the transaction.
The server answers ordinary successful traffic, the default success response when no redirect or conditional check changes the outcome
A common condition that triggers a 200 response when the web server evaluates the transaction.
Typical Scenarios
A browser navigates to a webpage and the server sends back the complete HTML document
An API client sends a valid search query and receives a JSON payload with the results
A client probes a URL with HEAD and receives the success status and headers with no body, because HEAD responses carry no content
A first-time download of an image or document completes with the full body, which caches can later revalidate because 200 responses are heuristically cacheable
What To Know
Reading what a 200 actually delivered means looking past the status: the method decides what the content represents, and the body may still carry an application-level failure. For caching, the validators a 200 response carries, such as ETag and Last-Modified, are the handles a client uses to revalidate later without transferring the resource again.
Frequently Asked Questions
Common interpretation questions about HTTP 200.
No. The entire 2xx range indicates success. 201 means a resource was created, 204 means success with no content body, 206 means only a part of the resource was returned, and 202 means the server took the request in but has not finished acting on it.
Both report success. A 204 response carries no additional content, it is terminated by the end of the header section and cannot contain content. A 200 response is expected to contain content unless the message framing explicitly marks it as zero length, and a request signaling a preference for no content on success gets 204 instead.
304 is the branch a conditional request takes when it would otherwise have produced 200: the request carried a freshness validator, an entity tag or a modification date, and the current representation still matches it. The server then points the client at its stored copy instead of transferring the content again. 200 is the first response, or the one after the validator stops matching.
At the HTTP layer, yes; at the application layer, not necessarily. A JSON API can return {"error": true} with a 200, where the exchange itself succeeded even though the business logic failed. The status code reports the transport outcome, and the body is where applications layer their own results.