204 vs 205: No Content vs Reset Content
Both codes are success responses with no body, but they differ in what they ask the client to do with its UI after the request.
| Aspect | HTTP 204 — No Content | HTTP 205 — Reset Content |
|---|---|---|
| RFC | RFC 9110, Section 15.3.5 | RFC 9110, Section 15.3.6 |
| Has body | No — MUST NOT include a body | No — MUST NOT include a body |
| Client action | Do nothing — stay where you are | Reset the UI element that triggered the request |
| Browser behavior on form submit | Stay on current page, no change | Stay on current page, clear the form fields |
| AJAX behavior | Promise resolves with empty response | Promise resolves; developer must call form.reset() |
| Cacheable | Yes (default) | No |
| Common use | DELETE, autosave, OPTIONS preflight | Reusable data-entry forms, comment submission, chat input |
204: Success, Nothing to Do
204 No Content says: “the operation succeeded and you do not need to do anything with the result.” The page stays as-is. No navigation, no form clearing, no UI changes required. It is the appropriate response when the operation has no side effect on the current user interface — background saves, delete confirmations, heartbeat pings.
// Autosave handler: just confirm success
app.patch('/api/drafts/:id', async (req, res) => {
await Draft.update(req.params.id, req.body);
res.sendStatus(204);
});205: Success, Reset the Form
205 Reset Content says: “the operation succeeded and the client should reset the initiating UI element to its initial state.” For a standard HTML form submission, this means the browser clears all form fields automatically. For an AJAX submission, the developer must call form.reset() explicitly when receiving 205.
// Comment form: clear after successful submission
app.post('/api/comments', async (req, res) => {
await Comment.create(req.body);
res.sendStatus(205); // signal: clear the comment form
});
// AJAX client handling 205
const res = await fetch('/api/comments', { method: 'POST', body: formData });
if (res.status === 205) {
commentForm.reset();
showToast('Comment posted!');
}205 is semantically precise: it communicates that the form should be ready for another submission immediately. Without it, the client has to make its own decision about whether to clear the form — which often ends in inconsistent behavior across different pages or scenarios.
Decision Rule
Use 204 for background operations where the UI does not need to change: DELETE, silent autosave, CORS preflight, heartbeats.
Use 205 for foreground form submissions where the form should be ready for immediate reuse: comment boxes, search bars, data-entry forms, chat input.
In practice, many teams use 200 with a JSON confirmation body for both cases and handle UI logic entirely in JavaScript. 204 and 205 are semantically richer but require client-side awareness of the status codes.
FAQ
Do browsers actually reset forms on 205?
Yes, for standard HTML form submissions (not AJAX). Chrome and Firefox both implement the HTML spec behavior of resetting forms on 205. For AJAX/fetch calls, no automatic reset occurs — the JavaScript code must call form.reset() explicitly.
Can I use 205 for a DELETE operation?
Technically yes if a form triggered the deletion and you want the form to reset. In most applications, deletion does not involve a form that needs resetting, so 204 is more appropriate. The choice depends on the specific UI context.
Why is 204 cacheable but 205 is not?
RFC 9110 makes 204 cacheable by default, likely because empty responses from GETs can be cached. 205 is not cacheable because it signals a dynamic UI state that should not be replayed. In practice, both should use Cache-Control: no-store when returned from write operations.
Full Guides
HTTP 204 No Content — full guide · HTTP 205 Reset Content — full guide · All comparisons