pingrobot

HTTP status codes / 204

204 No Content — HTTP Status Code

· 3 min read

Short answer

204 No Content means the server handled the request successfully and deliberately sent no body. APIs use it for deletes, updates and saves where there is nothing useful to return, and some health endpoints use it as a minimal "I am alive" reply. A 204 can never carry content, so anything that needs to read the body has nothing to read.

204 No Content is a success code with an empty response on purpose. The server did what was asked, and there is simply nothing to send back. The headers can still carry information, but the body is always empty.

What 204 means

RFC 9110 (Section 15.3.5) defines 204 as the server having successfully fulfilled the request with no additional content to send. A few specifics from the RFC:

  • Headers still count. Metadata in the response headers describes the target resource after the action. For example, a 204 to a PUT that includes an ETag tells the client the save worked and gives the new version's tag.
  • No navigation. A 204 implies the user agent does not need to move away from its current "document view." That is why it suits editors where a save button should not reload the page.
  • No body, ever. A 204 ends at the header section. It cannot contain content or trailers.
  • Cacheable by default. Like 200, a 204 is heuristically cacheable unless explicit cache controls say otherwise.

RFC 9110 also says that if a request indicates a preference for no content on success, a server ought to send 204 rather than an empty 200 OK.

When you see it

  • API writes. DELETE /items/42, PUT /settings, PATCH /profile with nothing to report beyond success.
  • CORS preflight. Many servers answer the browser's OPTIONS preflight with 204 and the Access-Control-Allow-* headers.
  • Analytics and beacons. Tracking endpoints commonly answer with 204, since the client never reads a reply.
  • Health and connectivity checks. Some services expose a health route that returns 204 when the process is up. Several operating systems and browsers also probe a known URL that returns 204 to detect whether a network has a captive portal; if the probe gets a login page instead, the device knows it is behind one.

Mistakes to avoid

  1. Sending a body anyway. Some frameworks let you write JSON into a 204 response. Proxies and clients may drop it, or on HTTP/1.1 it can confuse the framing of the next response on the connection.
  2. Clients that always parse JSON. Code like await res.json() throws on an empty 204 body. Check the status before parsing.
  3. Using 204 for "not found" or "no results." An empty search is still a successful search, so 200 with an empty list is clearer. A missing resource is a 404.
  4. Using 204 for a form submission in a browser. The page will not change, so the user gets no feedback unless JavaScript handles it.

How to check it

curl -I works, but a few servers answer HEAD differently, so it is worth seeing the GET too:

curl -sv -o /dev/null https://api.example.com/healthz

Look for:

< HTTP/2 204
< date: Thu, 15 Oct 2026 09:12:44 GMT

To confirm the body is really empty, print its size:

curl -s -o /dev/null -w "%{http_code} %{size_download}\n" https://api.example.com/healthz

The output should be 204 0.

What it means for uptime monitoring

A 204 is up. PingRobot's checker sends a GET, follows redirects, and counts any final status from 200 to 399 as up, so a health route that returns 204 works well for a plain HTTP(S) monitor.

What does not work is a keyword monitor on a 204 endpoint. A keyword check reads the body (up to the first 512 KB) and looks for a word you chose. A 204 has no body, so the word is never there: a "keyword must be present" check will report down every time, and a "keyword must be absent" check will always pass and tell you nothing. If you want to verify content, point the keyword monitor at a URL that returns 200 with a body, such as a health route that returns {"status":"ok"} and look for ok, or at a real page.

A related trap: a health route that always returns 204 regardless of the database or cache state proves only that the web process is running. Have it check its critical dependencies first, and return a 503 when one is failing.

Start monitoring free — 10 monitors, no credit card.

Frequently asked questions

Can a 204 response have a body?

No. RFC 9110 says a 204 ends with its header section and cannot contain content or trailers. A server that tries to send bytes after it is breaking the protocol.

Why does my browser stay on the same page after a 204?

That is intended. RFC 9110 describes 204 as telling the user agent it does not need to leave its current document view, which suits save buttons and background requests.

Should DELETE return 204 or 200?

Both are valid. 204 fits when there is nothing to report. Return 200 with a body if the client benefits from details, such as the deleted object or a remaining count.