2xx Success HTTP Status Codes
2xx codes indicate that the client’s request was received, understood, and accepted. Each code communicates a specific kind of success — from synchronous creation to asynchronous acceptance to partial content delivery.
All 2xx Codes
| Code | Name | Summary | Guide |
|---|---|---|---|
| 200 | OK | Standard success response. Body contains the requested resource or operation result. | Guide |
| 201 | Created | A new resource was created. Location header points to it. | Guide |
| 202 | Accepted | Request accepted; processing will happen asynchronously. | Guide |
| 203 | Non-Authoritative Information | Success, but response was modified by a transforming proxy. | Guide |
| 204 | No Content | Success with no body to return. Used for DELETE, autosave, and OPTIONS preflight. | Guide |
| 205 | Reset Content | Success; client should reset the form or UI that made the request. | Guide |
| 206 | Partial Content | Response to a range request. Body contains only the requested bytes. | Guide |
| 207 | Multi-Status | WebDAV: response body contains per-resource status codes for a batch operation. | Guide |
| 208 | Already Reported | WebDAV: resource already listed in this 207 response; deduplication marker. | Guide |
| 226 | IM Used | RFC 3229 delta encoding: response is a delta against a prior version. | Guide |
When to Use Each 2xx Code
200 OK: The Default
200 is the appropriate response for any successful GET request, for POST requests that perform an action and return a result, and for PUT or PATCH requests where you want to return the updated resource. The response body contains whatever the client requested or the result of the operation. If you are unsure which 2xx code to use, 200 is usually defensible, though the more specific codes below are preferable when they fit.
201 Created: When Something New Exists
Use 201 Created whenever a POST or PUT successfully creates a new, persistent resource. The response must include a Location header pointing to the new resource’s URL, and the body should contain the resource representation including any server-generated fields (ID, timestamps, computed properties). 201 tells clients that a new URL has been created and they can navigate to it immediately.
A common mistake: returning 201 for a POST that enqueues a job to create a resource. If the resource does not exist yet, use 202 instead. 201 means the resource exists right now.
202 Accepted: Async Operations
202 Accepted is the honest response for operations that take more time than a synchronous HTTP request should occupy. Video transcoding, report generation, bulk email sending, large data imports — all of these should return 202 with a job ID and a URL for polling status. Returning 200 after queuing a job is a lie: it tells the client the operation completed when it has not.
The 202 response body should always include enough information for tracking: a job ID, a status URL (also in the Location header), the current status, and an estimated completion time. RFC 9110 explicitly notes that 202 is “intentionally non-committal” — the operation may still fail.
204 No Content: Silent Success
204 No Content is for operations that succeed with nothing to return. The most idiomatic use is DELETE: after deleting a resource, there is nothing to return. Also appropriate for PATCH/PUT where the client already knows the new state, autosave endpoints that just need to confirm success, and CORS preflight responses (OPTIONS).
204 responses MUST NOT have a body. If you accidentally include a body with a 204, conforming clients will discard it. The point of 204 is to minimize payload size for high-frequency operations.
206 Partial Content: Video and Downloads
206 Partial Content is the response to an HTTP range request. HTML5 video players send range requests to seek within a video file. Download managers send range requests to resume interrupted downloads or fetch segments in parallel. A server that does not support range requests will not work correctly with these clients.
nginx and Apache return 206 automatically for static files when a Range header is present. Application servers must implement range request handling explicitly. The response must include a Content-Range header specifying which bytes are included and the total file size.
207 Multi-Status: Batch Operations
207 Multi-Status was designed for WebDAV batch operations but has been adopted by REST APIs with bulk endpoints. When a single request operates on multiple resources and some succeed while others fail, 207 lets the server return individual status codes for each resource in a single response. The client must parse the response body to determine which items succeeded and which failed.
The 200 vs. 204 Decision
A frequent design question in REST API development: when a DELETE or PATCH succeeds, should I return 200 or 204? Both are correct; the choice depends on what is useful to the client.
Return 200 if: the operation has side effects the client needs to know about (computed fields changed, related resources updated, a new version was generated), or if you want to include a confirmation payload for logging or display purposes.
Return 204 if: the client already knows the final state (it sent the complete new resource in a PUT), the operation has no meaningful result (DELETE, clear session), or you want to minimize response payload size for a high-frequency operation (autosave, heartbeat).