HTTP 204 No Content – Free, Online, Private

What HTTP 204 means

204 says the server did the thing and has nothing to send back. The response must not include a body. It is the right status for a DELETE that worked, a PUT that replaced a resource the client already has, or a form handler that should leave the current page in place. An empty 200 is a weaker version of the same idea, because clients may still try to parse a body.

204 No Content belongs to the 2xx successful class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 204

When you see HTTP 204 No Content, stop on that exact status line. 204 No Content means success and a deliberate absence of a body. The trace that usually produces it: DELETE removed the resource and there is nothing to echo. The 2xx successful class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 204 when success has no representation to return. Do not return 204 and a JSON body. Do not use 204 for a create if the client needs the new URL. Use 201. Do not use 204 to mean 'not found'. That is 404.

How to fix HTTP 204

To fix HTTP 204, change the condition that made the server choose No Content. Treat 204 as success and do not read a body. Update the UI from the request you already sent, or refetch if you need the server's copy. Retrying a DELETE or an idempotent PUT is safe. Retrying a POST that returned 204 may repeat a side effect. The empty body does not make POST idempotent. If the log line is a different code, leave this page. The mix-up people make with 204 is this one: 404 means the resource is absent and the request did not do what you asked. 205 Reset Content tells the client to reset its view. 204 does not ask for that.

• PUT replaced the resource and the client already sent the new bytes.
• A framework serialized null as a body on a 204 and intermediaries got confused.
• A browser form got 204 and stayed on the page, which is what the status is for, and the developer expected a redirect.

An access log that only stores 204 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 204 No ContentHTTP/1.1 204 No Content

No Content-Type is required because there is no body. Content-Length, if present, is 0. Anything after the header block is a protocol error. Clients must not try to parse JSON from this response.

What the client should do

Treat 204 as success and do not read a body. Update the UI from the request you already sent, or refetch if you need the server's copy.

A 204 can be cached in the sense that the stored response has no body. If the resource's GET representation should change, send cache validators or clear the relevant URL. Do not assume 204 invalidates every cached GET.

Retrying a DELETE or an idempotent PUT is safe. Retrying a POST that returned 204 may repeat a side effect. The empty body does not make POST idempotent.

Codes people confuse with HTTP 204

404 means the resource is absent and the request did not do what you asked. 205 Reset Content tells the client to reset its view. 204 does not ask for that.