HTTP 200 vs 201 vs 204 — When to Use Each Success Code
All 34 status codes · Search · Filter · Snippets · cURL Tester · Favorites
Choosing between HTTP success codes — 200 OK, 201 Created, 202 Accepted, 204 No Content, and 206 Partial Content. Each has a distinct semantic meaning. Using the right code makes your REST API more predictable, easier to debug, and correctly handled by HTTP clients, caches, and monitoring tools.
Click any status code to see full details, code snippets, and usage guide
Frequently Asked Questions
When should I use 200 OK vs 201 Created?
Use 200 OK when a request succeeds and returns existing data — GET, PUT, PATCH responses. Use 201 Created when a POST request successfully creates a new resource. With 201, include a Location: /resources/new-id header pointing to the new resource and return the created object in the body. Using 200 for creation is technically valid but loses semantic clarity.
When should I use 204 No Content?
Use 204 when a request succeeds but there is nothing to return — DELETE operations (resource deleted, nothing to send back), PUT/PATCH when you choose not to return the updated resource, and heartbeat/ping endpoints. If you want to return a confirmation message or the deleted record's final state, use 200 instead.
What is 202 Accepted and when should I use it?
202 Accepted means the request was received and will be processed asynchronously. Use it for long-running operations — email sending, video encoding, data imports, report generation. Return a job ID and status polling URL: {"jobId": "abc123", "statusUrl": "/jobs/abc123", "estimatedTime": 30}. The client polls the status URL until the job is complete.
What is 206 Partial Content?
206 Partial Content is returned when a client requests only part of a resource using the Range header. Used by video players (seek to position), download managers (resume downloads), and large file streaming. The response includes Content-Range header indicating which bytes are included. Most HTTP clients handle this automatically when you set up byte-range serving correctly.
Does 204 have a response body?
No — 204 must not include a response body. This is specified in RFC 9110. Sending a body with 204 is a protocol violation. If you need to return data, use 200 instead. Some frameworks automatically strip the body if 204 is set. In Express: res.status(204).send() — do not use res.status(204).json({}), as that would technically violate the spec.
Which 2xx codes are cacheable?
Cacheable 2xx codes per RFC 9110: 200 OK (with appropriate Cache-Control), 203 Non-Authoritative, 204 No Content, 206 Partial Content. Non-cacheable by default: 201 Created (new resource — cache would be invalid immediately), 202 Accepted (async — result not yet known). Always use Cache-Control headers explicitly rather than relying on default cacheability.