204 - No Content
HTTP 204 No Content is a success status code indicating that the server has fulfilled the request but there is no data to return in the response body. It is the standard response for successful DELETE operations and PUT updates where no representation is needed.
Last reviewed: March 9, 2026|Editorial standard: source-backed technical guidance
What Does No Content Mean?
A 204 response is a "Bodyless Success." While the operation is successful, the intentional absence of a response body often triggers a "SyntaxError: Unexpected end of JSON input" in clients that unconditionally call .json(). In RESTful design, 204 signals that the action was performed (like a deletion) and the client should stay on the current page or state without expecting new data.
Common Causes
- -Unconditional JSON Parsing: The client-side code calls
response.json()on a 204 response, which throws an error because the body is empty (0 bytes). - -Stale UI State: The server returns 204 after a DELETE, but the frontend fails to manually update the local cache, making it appear as if the item still exists.
- -CORS Preflight (OPTIONS): Browsers often send an OPTIONS request before the real request; if the server doesn't return 204 (or 200) with proper headers, the main request is blocked.
- -Cache Inconsistency: A proxy or CDN caches a 204 response incorrectly or fails to invalidate a previous GET response after a successful DELETE/PUT.
How to Fix No Content
- 1Status Guard: Wrap your parsing logic with
if (response.status !== 204) { await response.json(); }. - 2Optimistic UI: Immediately remove the deleted record from your state manager (Redux, React Query) once a 204 is received.
- 3CORS Header Check: Ensure your server returns 204 for OPTIONS requests with the necessary
Access-Control-Allow-Methodsheaders. - 4Verify Content-Length: Ensure the server sends
Content-Length: 0or omits it entirely; sending any byte (even a space) violates the 204 spec.
Step-by-Step Diagnosis for No Content
- 1Open Browser DevTools > Network tab and verify that the "Response" tab for the 204 request is completely empty.
- 2Check the "Console" for
SyntaxErrororUnexpected end of inputexceptions following a network call. - 3Inspect the
Content-Typeheader; a true 204 should ideally not have aContent-Typesince there is no content to describe. - 4Audit your API Gateway to ensure it isn't injecting an empty object
{}into the 204 response, which confuses some clients.
Success Status Decision Matrix
- -Use 204: For DELETE or PUT when the client already has the latest state and no data transfer is needed.
- -Use 200 OK: For PUT/PATCH if the server-computed values (like
updated_at) must be synced back to the client. - -Use 205 Reset Content: If the success should trigger the client to clear the current view (e.g., reset a form).
The "DELETE Idempotency" Rule
- -Standard Case: Returning 204 for an existing resource deletion.
- -Idempotent Flow: Some APIs return 204 even if the resource is already gone (instead of 404) to prevent client-side logic from handling "errors" on something that is already in the desired state.
Implementation Examples
curl -i -X DELETE https://api.errorreference.com/v1/posts/55
# Expected Output:
# HTTP/1.1 204 No Content
# Content-Length: 0
# (No body displayed)const deleteRecord = async (id) => {
const res = await fetch(`/api/v1/records/${id}`, { method: 'DELETE' });
// Guard against 204 to avoid JSON SyntaxError
if (res.status === 204) {
console.log('Deleted successfully. No body to parse.');
return null;
}
return await res.json();
};How to Verify the Fix
- -Confirm the status code is exactly 204 and no JSON parse errors appear in the console.
- -Perform a subsequent GET request to the resource and verify it returns 404 (if deleted) or reflects the update.
- -Ensure the UI reflects the change (e.g., row disappears) without a page refresh.
How to Prevent Recurrence
- -Standardize API Wrappers: Use a global fetch/axios interceptor that returns
nullor an empty object for 204 status codes automatically. - -Prefer 200 for Updates: For PUT operations, consider returning 200 with the full updated object to eliminate "stale state" bugs.
- -Contract Testing: Use tools like Prism to ensure the backend never accidentally sends a body with a 204 status.
- -Pro-tip: For CORS preflight, always use 204 as it is more performant and follows the W3C recommendation for pre-flighted requests.
Decision Support
Compare Guide
403 Forbidden vs 404 Not Found: When to Hide Resources
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.
Compare Guide
404 Not Found vs 410 Gone: Missing vs Permanent Removal
Learn when to return 404 (missing or temporary absence) versus 410 (intentional permanent removal), including redirect and cache implications.
Playbook
Resource State Playbook (404 / 410 / ResourceNotFound)
Use this playbook to separate temporary missing-resource lookups from permanent removals, then fix scope, lifecycle, and identifier drift safely.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.