Why does response.json() fail on a 204?
A 204 has no body by definition, so there is nothing to parse and the JSON parser throws. Check for status 204, or for an empty body, before reading JSON.
Success with no body. Common for DELETE and for saves that return nothing. 204 belongs to the 2xx success class and is defined in RFC 9110.
Loading the workbench.
Success with no body. Common for DELETE and for saves that return nothing. The code is registered with IANA and defined in RFC 9110.
Success: the request was received, understood, and accepted. Every code from 200 to 299 shares that general meaning, so a client that does not recognise 204 must treat it like 200.
204 No Content signals success with deliberately nothing in the body. It is the natural answer to a DELETE, to a PUT or PATCH that saves without echoing the result, and to analytics beacons and CORS preflights that only need a yes. Browsers that receive 204 from a form submission or link stay on the current page. Any body bytes a buggy server sends after a 204 are ignored or can corrupt the next response on a reused connection.
Servers must not send a body or a Content-Length other than zero; frameworks that serialize null into the string null break this rule. Headers still matter, so include an ETag after a save to let the client update its cached validator. Clients should not try to parse JSON from a 204; check the status before calling the parser, since response.json() throws on an empty body.
HTTP/1.1 204 No Content
ETag: "v42"
Date: Tue, 10 Nov 2026 18:00:00 GMT204 is cacheable by default under RFC 9110: a browser or CDN may store it and reuse it even without explicit freshness headers, using a heuristic lifetime. Send Cache-Control to say exactly how long.
To inspect a real one without sending it anywhere:
curl -i.Browse every code on the HTTP status codes page.
Elsewhere in 2http: Header decoder, Cookie decoder, Cache-Control decoder, CORS checker, User-agent parser, and all eleven lanes on the 2http home page. Part of the 2suite.io privacy-first ecosystem.
A 204 has no body by definition, so there is nothing to parse and the JSON parser throws. Check for status 204, or for an empty body, before reading JSON.
Use 204 when there is nothing useful to return, and 200 with a body when you want to return the deleted item or a confirmation message. Both are correct.
No. 204 is a success response, not an error.
Yes. RFC 9110 lists 204 as heuristically cacheable, so caches may store it without explicit headers. Use Cache-Control to control how long.
You do not have to take our word that your headers stay here. Developer tools show every request a page makes, so you can watch this page work and confirm that nothing is sent. The check takes under a minute.
F12, or Cmd+Option+I on a Mac, and select the Network tab.Only two things can add a line to that log, and neither carries your headers. Submitting the feedback form sends the vote and comment you typed. Typing characters in a script the page has not displayed yet, such as Cyrillic or Greek, can make the browser fetch the matching font file, and that request names only the font.
2http never sends a request on your behalf: the request builder writes code for you to run, and the meta inspector reads source you paste instead of fetching a URL. The production site also sends a Content-Security-Policy header that tells your browser to refuse connections to anywhere except this site and the anonymous analytics endpoint.