200 OK

This is an educational reference page about HTTP 200 OK. The page itself is served as 200 OK so it can be indexed as HTTP documentation.

The request succeeded. What the response body contains depends on the request method.

Specification

Registered in the IANA HTTP Status Code Registry as OK. Defined in RFC 9110, Section 15.3.1.

What it means

HTTP 200 OK means the request succeeded. The body depends on the method: a GET returns the requested resource, a POST returns the result of the action, and a PUT or DELETE returns the status of the action.

When to use it

Return 200 for a successful GET that sends the resource back.
Return 200 for a successful POST, PUT, PATCH, or DELETE when the response has a body worth reading, such as the updated resource.
Use 201 instead when the request created a new resource, and 204 when there is nothing to send back.

Headers involved

Content-Type describes the response body.
ETag and Last-Modified let clients make conditional requests later. RFC 9110 says a server SHOULD send available validators in 200 responses to GET and HEAD.
Cache-Control controls caching. 200 is heuristically cacheable, so caches may store it even when the response has no Cache-Control or Expires header.

Examples

GET a resource

GET /api/orders/1042 HTTP/1.1
Host: api.example.com
Accept: application/json

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

{
  "id": 1042,
  "status": "paid",
  "total": "49.00"
}

PATCH that returns the updated resource

PATCH /api/orders/1042 HTTP/1.1
Host: api.example.com
Content-Type: application/merge-patch+json

{
  "status": "shipped"
}

HTTP/1.1 200 OK
Content-Type: application/json
ETag: "b71c"

{
  "id": 1042,
  "status": "shipped",
  "total": "49.00"
}

Common mistakes

Returning 200 with an error object such as {"status":"error"}. Monitors, caches, retries, and client libraries treat the request as a success.
Returning 200 with an empty body when 204 is what the client should expect.
Letting a 200 response to a personalized GET be cached by shared caches. Send Cache-Control: private or no-store when the response is specific to the user.

Developer notes

200 is the default success code, so most of the work is deciding when another 2xx code fits better. Send 201 when the request created a resource, 202 when the work runs later, and 204 when there is nothing to return.

Questions

What does HTTP 200 OK mean?

HTTP 200 means the request succeeded. The response body depends on the method: a resource for GET, or the outcome of the action for POST, PUT, and DELETE.

Should an API return 200 or 201 after POST?

Return 201 when the POST created a resource. Return 200 when the POST performed an action that did not create a new resource, such as a search or a calculation.

Can a 200 response have no body?

Yes, if the framing says the length is zero, but 204 No Content says it more clearly.

Header and content rules

What RFC 9110 says about a 200 response, quoted from the RFC.

SHOULD (origin server; ETag, Last-Modified): Send any available validator fields. A strong ETag plus Last-Modified is preferred. When: Responses to GET or HEAD. Table row
In 200 responses to GET or HEAD, an origin server SHOULD send any available validator fields (Section 8.8) for the selected representation, with both a strong entity tag and a Last-Modified date being preferred. RFC 9110 §15.3.1

The same rule is in the response obligations table and its JSON.