204 No Content
The request succeeded but there is no response body, and the client should keep displaying its current view.
Defined in RFC 9110 §15.3.5
What 204 means
HTTP 204 No Content signals that a request succeeded and, deliberately, there is nothing to send back in the response body. It is the standard response for operations where the client already has all the information it needs, most commonly a successful DELETE, a PUT or PATCH update where the client does not need the updated representation echoed back, or a form submission where the current page should simply stay as it is. Because there is no body, the response must not include a Content-Length other than zero or a Content-Type header describing entity content, since there is no entity.
Browsers treat 204 specially in a few contexts: submitting a form to an endpoint that returns 204 leaves the current page in place rather than navigating anywhere, and some analytics beacons deliberately use 204 for exactly that reason, to fire a background request without triggering any navigation or rendering. This makes 204 popular for tracking pixels, health check endpoints, and any fire-and-forget request where the caller only cares whether the call succeeded, not what came back.
204 differs from 200 with an empty body mainly in intent and in how strictly clients should interpret it: an empty 200 body could just be an unusual but valid representation, whereas 204 explicitly states no representation exists or is being returned. REST APIs commonly use 204 for successful DELETE requests and for PUT or PATCH requests where the client does not need the server to echo back the updated resource, reserving 200 for cases where returning the updated representation actually helps the caller.
Common causes
- A DELETE request successfully removed a resource and there is nothing meaningful to return.
- A PUT or PATCH request updated a resource and the API is designed not to echo the updated representation back.
- An analytics or tracking endpoint intentionally returns an empty body to avoid triggering any page navigation.
- A form is submitted via fetch or XHR to an endpoint that processes it without needing to render a new page.
- A health check or heartbeat endpoint confirms liveness with no payload.
How to fix a 204
If you are the client (browser user or API caller)
- Do not attempt to parse a body from a 204 response; check only the status code for success or failure.
- After a successful DELETE that returns 204, remove the item from local state or cache rather than expecting a confirmation body.
- Use fetch or XHR, not a full page form submission, when you want a 204 endpoint to run without navigating away from the current page.
If you run the server
- Return 204 instead of 200 with an empty JSON object for successful DELETE, and for PUT or PATCH calls that do not need to echo the resource back.
- Make sure no Content-Length other than zero, or entity Content-Type header, is sent alongside a 204 response.
- Reserve 204 for genuinely empty successful responses; return 200 with a body whenever the client benefits from seeing the result.
Example
DELETE /api/orders/8842 HTTP/1.1
Host: api.example.com
Authorization: Bearer token123
HTTP/1.1 204 No ContentTry it live
Our free status responder returns a real HTTP 204 you can point tests, monitors or a browser at.
GET https://mcp.httpstatus.com/status/204