204 No Content 2xx
The request succeeded, but there is no content to send in the response body.
What does 204 mean?
A 204 No Content response means the request succeeded, but there's intentionally nothing to send back in the response body. It's a deliberate "yes, that worked, and there's nothing more to say about it" — distinct from an empty 200 response, which (per spec) implies a body could be present, just happens to be empty.
204 is most commonly associated with DELETE requests: when you delete a resource, there's often nothing meaningful left to return — the resource is gone, so returning its (now-deleted) representation doesn't make sense, and there's no new data to send.
How a 204 behaves
- It must not include a message body — this is part of the spec, not just a convention; clients shouldn't expect (or attempt to parse) body content on a 204
- It can still include headers — caching headers, custom headers, etc. can be present even though the body is empty
- It's commonly used for DELETE — but also applies to PUT/PATCH operations that succeed without needing to return the updated resource, and occasionally to POST actions that trigger something without producing a result to return
- Browsers handle it gracefully for certain interactions — e.g., some background requests (like
navigator.sendBeaconor certain fetch calls for "fire and forget" actions) work well with 204 since there's no body to process
Common scenarios
If you're building an API:
- A successful DELETE request is the most common candidate for 204 — the resource no longer exists, so there's nothing to return
- A PUT/PATCH that updates a resource but where the client doesn't need the updated representation back (perhaps because the client already has the data it sent and the server made no additional changes) can return 204 instead of echoing the resource back in a 200
- An action endpoint that performs a side effect (e.g., "mark as read," "trigger a process") without any data to return as a result is a good candidate for 204
If you're calling an API:
- A 204 response confirms success — don't attempt to parse a body, as there isn't one
- For DELETE operations, a 204 (rather than, say, a 404 on a subsequent GET for the deleted resource) is the cleanest immediate confirmation that the deletion succeeded
If you're a website visitor:
- 204 is purely an API/background-request concept; you won't directly "see" a 204, though actions on a page (like deleting an item from a list) might trigger a 204 behind the scenes before the UI updates
200 vs 201 vs 204
| Code | Meaning | When to use |
|---|---|---|
| 200 OK | General success, response includes relevant data | Default success response for GET, and for POST/PUT/PATCH operations that don't specifically create a new resource |
| 201 Created | Success, and a new resource now exists | POST requests that result in a new resource — include Location header and the created resource in the body |
| 204 No Content | Success, nothing to return | Operations that succeed but have no meaningful body to send back — common for DELETE, sometimes PUT/PATCH |
Real-world examples
Many REST APIs return 204 for successful DELETE requests as a matter of convention — confirming the deletion without needing to echo back the now-nonexistent resource. Some browser APIs and tracking/analytics endpoints specifically use 204 for "fire and forget" requests, where the client sends data (e.g., a page-view event) and the server simply acknowledges receipt with no meaningful response needed.
SEO implications
204 is exclusively relevant to API-style interactions and has no direct bearing on page-level SEO — indexable content always requires a body to be useful to search engines (and to users), so 204 would never be an appropriate response for a page meant to be crawled and indexed.
FAQ
What's the difference between a 200 with an empty body and a 204?
A 200 with an empty body technically implies a body could have been present (the spec allows for it), even if this particular response happens to be empty. A 204 explicitly signals "there is no body, by design" — it's a more precise, intentional signal than an incidentally-empty 200.
Is 204 only used for DELETE requests?
DELETE is the most common use case, but 204 can apply to any successful operation where there's nothing meaningful to return — certain PUT/PATCH updates, action-triggering POST requests, and similar "did the thing, nothing to show for it" operations.
Can a 204 response include headers?
Yes — only the body is empty by definition. Headers (including caching headers, custom application headers, etc.) can still be present on a 204 response.
If I delete a resource and get 204, then immediately try to GET it, what happens?
You'd typically get a 404 Not Found, since the resource no longer exists. The 204 from the DELETE confirms the deletion succeeded; the subsequent 404 on a GET confirms the resource is now gone — these two responses are consistent with each other, not contradictory.
Why would an API choose 204 over 200 for an update operation?
If the client already has all the data it needs (it sent the update, and the server made exactly those changes with no additional server-generated changes to report back), returning the same data again in a 200 is redundant. A 204 avoids sending unnecessary data back over the network — though many APIs still choose to return the updated resource in a 200 for convenience, so both patterns are common.
Fun fact
204 is one of the only status codes where the absence of something (a body) is the entire point — most status codes communicate information through their number and an accompanying body, but 204's defining characteristic is explicitly that there's nothing else to communicate, making it a rare example of "the lack of content is the content."