HTTP 200 OK
When you see HTTP 200 in a browser network tab or server log, it means the round trip completed: the request reached the server, the server understood it, processed it, and is sending back a body. For a user, this usually means the page loaded or the action completed. For a developer reviewing logs, 200 is the baseline — no action needed at the protocol level.
The common confusion with 200 is that it only means the HTTP layer succeeded, not that the application logic inside succeeded. Some older APIs (especially SOAP and legacy REST implementations) return 200 with an error body like {"status":"error","code":"payment_failed"}. This breaks monitoring — error rates look flat even when every transaction is failing. If you are designing an API, map application errors to appropriate 4xx codes so infrastructure and client tooling can detect them without parsing the body.
Quick reference
| Code | 200 |
|---|---|
| Name | OK |
| Category | 2xx success |
| Specification | RFC 9110 |
| IANA status | Assigned |
| When to use | Return 200 when the request succeeded and there is a body to return. For successful creation use 201. For successful deletion or updates with no body use 204. Avoid wrapping error messages inside 200 responses — it breaks client error handling and monitoring dashboards. |
| Client behavior | Clients display the response body as-is. Browsers render the page. API clients parse the JSON body. No retry is attempted. If caching headers are present, the response may be stored. |
| Caching | Cacheable by default if Cache-Control, Expires, or Last-Modified headers are present. Without explicit cache headers, client behavior varies. Set Cache-Control: no-store for dynamic API responses, or appropriate max-age for stable resources. |
Common causes
- Standard successful HTTP request
How to fix it
- No fix needed — this is the expected success response
Example exchange
GET /api/users/1 HTTP/1.1
Host: api.example.com
HTTP/1.1 200 OK
Content-Type: application/json
{"id":1,"name":"Alice"}When you see this in production
In production logs, 200s make up the majority of traffic on any healthy endpoint. They appear in access logs, APM traces, and CDN dashboards as the baseline success signal. Key things to watch:
- Latency distribution on 200s (a slow 200 is still a user-facing problem)
- Body size anomalies (unexpectedly large or empty 200 bodies can indicate truncation or serialization bugs)
- 200s on endpoints that should return 201 or 204 (indicates a generator that is not following REST conventions)
What developers usually do next
- When you receive an unexpected 200:
- - Check the response body — the API may be embedding errors inside it
- - Validate the Content-Type header matches what you expect (application/json vs text/html)
- - If a redirect was expected, check whether your HTTP client is following redirects silently and you are seeing the final 200
- - Confirm the response body matches your schema; a 200 with empty body or unexpected structure is a bug in the upstream service
When NOT to use this code
Do not return 200 for: successful resource creation (use 201 instead), successful requests with no response body (use 204), requests that have been accepted for async processing (use 202), or responses where the main content is an error message (use the appropriate 4xx or 5xx code instead).
Related status codes
HTTP 201 Created · HTTP 204 No Content · HTTP 206 Partial Content
Comparisons
HTTP 200 vs 103 · HTTP 200 vs 201 · HTTP 200 vs 204 · HTTP 200 vs 202 · HTTP 200 vs 206 · HTTP 200 vs 207 · HTTP 200 vs 226 · HTTP 200 vs 304
Frequently asked questions
Does HTTP 200 always mean the response body is correct?
Not necessarily. A 200 can accompany an error message in the body if the application does not map errors to appropriate status codes. Always validate the response body separately.
Can a 200 response be cached?
Yes, if appropriate Cache-Control or Expires headers are set. Without those headers, caching behavior depends on the client and intermediary.
Standards reference
This definition is derived from the IANA HTTP Status Code Registry and RFC 9110. Human-readable operational guidance by ErrorLookup. · HTTP 200 quick reference →