HTTP Status 204 (No Content)

HTTP Status 204 (No Content) indicates that the server has successfully fulfilled the request and that there is no content to send in the response payload body. Server might want to return updated meta information in the form of entity-headers, which if present SHOULD be applied to current document’s active view if any.

HTTP Status 204 (No Content) indicates that the server has successfully fulfilled the request and that there is no content to send in the response payload body. In other words, it communicates that the request was processed successfully, but there is no new information to send back to the client. It is documented in RFC-7231 that can be consulted when more technical details are needed.

With status 204, the server might want to return updated meta-information in the form of HTTP headers, which, if present, SHOULD be applied to the current document’s active view if any.

The 204 response MUST NOT include a message body and thus is always terminated by the first empty line after the header fields.

1. HTTP 204 Response is Cacheable

By default, 204 (No Content) the response is cacheable. If caching needs to be overridden then the response must include cache respective cache headers.

For example, we may want to return status 204 in UPDATE operations where the request payload is large enough not to transport back and forth. The user agent will send the payload to the server to update the resource.

If the operation is successful, the server will respond with 204 to indicate the success so that the client application can update its UI to inform the user about the operation’s success.

It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems.

2. Resolving the Lost Update Problem

With status 204, the server may also include an HTTP header ETag to let the client validate client-side resource representation before making a further update on the server – to avoid the lost update problem.

The lost update problem happens when multiple people edit a resource without knowledge of each other’s changes. In this scenario, the last person to update a resource “wins,” and previous updates are lost.

ETags can be used in combination with the If-Match header to let the server decide if a resource should be updated. If ETag does not match then the server informs the client via a 412 (Precondition Failed) response.

3. Best Practices

When using HTTP 204, consider the following best practices:

  • Ensure that the response is appropriately documented and the client understands that no content will be returned.
  • Use HTTP 204 for scenarios where confirming the request’s success without additional data is meaningful, and a different status code would be less accurate.

4. Summary

When a client receives an HTTP 204 response, it should recognize that the request was successful but that no data is included in the response body. While the absence of content is the defining feature of 204, clients should still consider other aspects of the response, such as headers, for additional information.

Happy Learning !!


Notify of
Oldest Most Voted
Inline Feedbacks
View all comments
Kiril Karagyozov

In a REST API’s world, is it outlined in the specifications somewhere if one ought to return a 204 HTTP Status code ever in response to a GET request?

If a resource does not exist – 404 should be returned. If a collection of resources do not exist or conform to the specified filters – Is it 200 OK, as the resource DOES exist in the form of an empty database table, or rather 204 No Content, as again, the resource does exist in some form, but there’s no content to return?

Right now I’m on camp that a 204 should never be returned in response to a GET request in a REST API for a resource. When you fetch a resource – it either exists (HTTP 200 OK), or it doesn’t. (HTTP 404 NOT FOUND) – but I’m not sure if the specifications state the same. HTTP 204 would then be used only in controller endpoints.


Joseph C

I generally only return a 204 with PUT requests. Maybe sometimes on a POST, depending on the circumstances.

rajsekhar mahapatro

Hi for a request i am returning a certain type of Object say a City object, now if i make a request for a resource which doesn’t exists now how to handle the no content request? Remember i am returning a City Object.

Marc Donovan

that’s a 404, not a 204

Jeroen Verschuuren

Depends on what you asked for:
If you requested a list of a sub-resource then I would return a 204 – No content

If you requested a single (sub-)resource then I would return a 404 – Not found

Adam Kent

If you’re requesting a collection (e.g. I would return:

404 if /authors/123 does not exist
200 with an empty collection otherwise

I would not ever return a 204 in response to a GET