204 No Content

What do you say when there's nothing to say?

You say nothing. That's 204.

The 204 No Content status code represents success without response content. The server processed your request completely, accomplished what you asked, and has nothing to send back. This might seem odd—why succeed with nothing to show?—but 204 is often the most honest response possible.

The Shape of Silence

A 204 response is remarkably spare:

HTTP/1.1 204 No Content
Date: Wed, 21 Oct 2024 07:28:00 GMT

No Content-Type. No Content-Length. No body. The headers end, and that's it. The response is complete.

This isn't emptiness by accident. It's emptiness by design.

When Silence Is the Right Answer

Deleting Things

The most natural use of 204:

DELETE /api/users/123 HTTP/1.1

HTTP/1.1 204 No Content

The user is gone. What would you return? The deleted user? That's contradictory—you just said it doesn't exist. An empty object? That's noise pretending to be signal. A success message? That's what the status code already says.

204 is the only honest answer: the deed is done, and there's nothing more to say.

Updates Without Echo

When you update a resource but don't need the server to echo it back:

PUT /api/users/123 HTTP/1.1
Content-Type: application/json

{"name": "Alice Updated", "email": "alice@example.com"}

HTTP/1.1 204 No Content

You told the server the new state. The server accepted it. Why would it repeat what you just said? If you need to confirm the update, make a GET request. But often, you trust your own message.

Actions That Just Happen

Some operations produce effects, not outputs:

POST /api/cache/clear HTTP/1.1

HTTP/1.1 204 No Content

POST /api/users/123/reset-password HTTP/1.1

HTTP/1.1 204 No Content

The cache is cleared. The password reset email is sent. Success. What content would you return? The password? Obviously not. A confirmation message? The status code is the confirmation.

204 vs. Its Neighbors

200 OK: "Here's the thing you asked for." Use 200 when you have content to return.

201 Created: "I made a new thing, and here's where to find it." Use 201 when creating resources.

202 Accepted: "I'll do this later." Use 202 when processing is deferred.

204 No Content: "Done. Nothing more to say." Use 204 when the operation succeeded and silence is the appropriate response.

The distinction between 200 and 204 matters for efficiency. A 200 response with {"success": true} wastes bytes. The client has to parse JSON just to learn what the status code already told it. 204 eliminates that waste—no body to transfer, no JSON to parse.

The No-Body Rule

204 responses must not contain a message body. This isn't a suggestion—it's the specification. The response ends after the headers:

HTTP/1.1 204 No Content
Date: Wed, 21 Oct 2024 07:28:00 GMT

Nothing follows. Some HTTP libraries will wait for content that never arrives if they don't handle 204 correctly, causing timeouts. The emptiness is intentional.

Headers you shouldn't include:

• Content-Type: No content means no content type
• Content-Length: Omit it, or set it to 0
• Transfer-Encoding: Nothing to encode

Headers you can include:

• Date: When the response was generated
• Cache-Control: Caching directives
• Custom headers: Request IDs, rate limits, etc.

Strange Browser Behavior

When browsers receive 204, something interesting happens: nothing.

A form that submits to an endpoint returning 204 doesn't navigate. The page stays exactly where it is. The form submits, the server responds with success, and the browser just... continues. No page change. No redirect. The user might not even notice anything happened.

<form action="/api/update" method="POST">
    <input type="text" name="value">
    <button type="submit">Update</button>
</form>

If /api/update returns 204, clicking submit does nothing visible. This can be useful (background saves) or confusing (users wondering if it worked). Design accordingly.

Client Code That Doesn't Break

The common mistake is trying to parse a body that doesn't exist:

// This will fail
const response = await fetch('/api/users/123', { method: 'DELETE' });
const data = await response.json(); // Error! No content to parse

Check for 204 before parsing:

const response = await fetch('/api/users/123', { method: 'DELETE' });

if (response.status === 204) {
    // Success, nothing to parse
    return { success: true };
}

if (response.ok) {
    // Success with content
    return await response.json();
}

throw new Error(`Request failed: ${response.status}`);

Or more defensively:

async function request(url, options) {
    const response = await fetch(url, options);
    
    if (!response.ok) {
        throw new Error(`Request failed: ${response.status}`);
    }
    
    if (response.status === 204) {
        return null;
    }
    
    const contentType = response.headers.get('Content-Type');
    if (contentType?.includes('application/json')) {
        return await response.json();
    }
    
    return await response.text();
}

When Not to Use 204

When clients expect content: If your API consumers need the updated resource back, return 200 with the resource. Don't make them guess or make a second request.

When creating resources: Resource creation should return 201 with the new resource's location (and often its content). 204 after a POST that creates something is confusing.

For errors: Never use 204 for errors. If a DELETE targets a resource that doesn't exist, return 404. If something went wrong, return the appropriate 4xx or 5xx code with an error body. 204 means success.

The Elegance of Nothing

204 embodies a principle: don't say more than necessary.

When an operation succeeds and there's genuinely nothing to communicate beyond that success, 204 is the perfect response. It saves bandwidth. It saves parsing. It says exactly what needs saying—that the operation worked—and nothing more.

The next time you're designing an API endpoint and wondering what to return, ask yourself: is there actually anything to say? If the answer is no, 204 is your answer too.