200 OK
The request succeeded. What the body contains depends on the method that was used.
Status
HTTP/1.1 200 OK
Details
- Category: 2xx
- Status: Standard. Registered with IANA and defined by a current standards-track RFC.
- Specification: RFC 9110 §15.3.1
- Cacheable: Cacheable by default
- Response body: Allowed
- Retry: Not applicable
200 is the default success response. The meaning of the payload follows the request method: for GET it is the representation of the target resource, for HEAD it is the same headers with no body, for POST it is the result of the action, and for PUT or DELETE it is a status description rather than the resource itself.
A 200 says nothing about the content being correct or complete. Applications routinely return 200 with an error object in the body, which is legal but hostile to caches, monitoring, and retry logic. If the request failed, use the code that says so.
Note: A 200 describes the exchange, not your business logic. An API that reports failures inside a 200 body defeats caching, monitoring, and client retry logic, all of which read the status line.
Headers
- Content-Type: Tells the client how to parse the body. Missing or wrong values are a common source of silent parse failures.
- Cache-Control: Controls storage and reuse. Without it, caches apply heuristics to a 200.
- ETag: Enables conditional requests so later fetches can return 304 instead of the full body.
Common causes
- The request was valid and the server produced a representation.
- An API returned an application-level error inside a 200 envelope, which is a design choice rather than a protocol condition.
Usage notes
For clients
- Check the Content-Type before parsing. A 200 serving an HTML block page instead of JSON is the classic scraping failure.
- Inspect the body when an API wraps errors in a 200. Response code alone is not enough to know a call succeeded.
For servers
- Return the code that matches the outcome. Errors in a 200 body break caching and client retry logic.
- Set validators (ETag or Last-Modified) so repeat requests can be answered with 304.
Examples
Fetching a resource
A conditional-request-friendly GET against a JSON API:
HTTP request
GET /api/orders/8814 HTTP/1.1 Host: api.example.com Accept: application/json
The server returns the representation, along with an ETag so the next fetch can be answered with 304:
HTTP response
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 87
ETag: "8f4c1a"
Cache-Control: private, max-age=60
{"id":8814,"status":"active","ips":4,"renews_at":"2026-09-01T00:00:00Z"}
Notes for proxy users
A 200 does not prove a scrape worked. Anti-bot systems commonly answer automated traffic with a 200 carrying a challenge or an empty shell page, so validate content and not just the status line when testing a proxy pool.