205 Reset Content 2xx
The server successfully processed the request and asks the client to reset the document/form view that sent it.
What does 205 mean?
A 205 Reset Content response means the request succeeded, and the server is specifically telling the client's user agent to reset the view that submitted the request — most concretely, clearing a form back to its default/empty state, as you'd want after a successful submission so the user doesn't accidentally resubmit the same data.
Like 203, this is one of the rarer status codes — the use case (server explicitly instructing a form reset via status code) is something most web applications handle through other means (redirecting after submission, JavaScript clearing form fields, etc.) rather than relying on 205's specific semantics.
How a 205 behaves
- It carries no body, similar to 204 — there's nothing to display, just an instruction to reset the view
- It's specifically about the client-side view/form, not about the underlying resource on the server — distinguishing it from 204, which is more general-purpose "succeeded, nothing to return"
- It requires client support for the "reset" instruction to have any visible effect — a client that doesn't specifically implement 205's reset behavior would likely just treat it similarly to 204 (success, no body), without actually resetting any form
Common scenarios
If you're building the website:
- After a form submission succeeds, you want the form to clear back to empty/default values (rather than, say, retaining the submitted values) — 205 is the spec-defined way to signal this, though in practice, redirecting to a fresh page (which naturally shows an empty form) or using client-side JavaScript to reset form fields are far more commonly used approaches
- 205 sees more relevance in non-browser HTTP clients/contexts where "the view" has a more specific defined meaning than in typical HTML form submissions
If you're calling an API:
- Essentially never relevant — "resetting a view" is a browser/UI concept, not something API clients typically have
If you're a website visitor:
- If a site used 205 (which is uncommon), you might notice a form clearing itself after successful submission — though this effect is much more commonly achieved via other techniques (page redirects, JavaScript)
204 vs 205
| 204 No Content | 205 Reset Content | |
|---|---|---|
| Meaning | Succeeded, nothing to return | Succeeded, AND the client should reset the view that sent the request |
| Body | None | None |
| Client-side effect implied | None specifically | Reset/clear the relevant form or view |
Real-world examples
205 is rarely seen in modern web development — the common pattern of redirecting after a successful form POST (the "POST/redirect/GET" pattern, often using 302/303) naturally results in a fresh page with an empty form, achieving a similar user-facing outcome without relying on 205's specific semantics, which not all clients implement meaningfully anyway.
SEO implications
None — 205 relates to form-submission UI behavior, not page content or crawling.
FAQ
What's the practical difference between 204 and 205?
204 simply says "succeeded, nothing to return." 205 adds a specific instruction: "succeeded, AND please reset the view/form that made this request" — though whether a client actually does anything different in response to this instruction depends on whether it implements 205's semantics specifically.
Why don't more sites use 205 for form resets?
The "POST/redirect/GET" pattern (responding to a form POST with a redirect to a fresh page) achieves a similar visual outcome — an empty form — through a different, more universally-supported mechanism, without depending on clients implementing 205's specific reset behavior.
Do browsers actually reset forms on 205?
Support and behavior can vary, and because of this inconsistency, many developers don't rely on it — preferring redirects or JavaScript-based form clearing, which provide more predictable, consistent results across browsers.
Is 205 used in non-browser contexts?
The concept of "the view that sent the request" is somewhat browser/form-centric, making 205 less applicable to typical API/non-browser HTTP interactions, which is part of why it's rarely encountered outside of (uncommon) browser-form scenarios.
Should I implement 205 in my application?
Given inconsistent client support and the availability of more reliable alternatives (redirects, client-side JS) for achieving similar outcomes, there's limited practical benefit to specifically implementing 205 for modern web applications.
Fun fact
205 represents a small family of status codes (alongside 203) where the HTTP specification defined fairly specific behavioral semantics that, in practice, the broader web ecosystem largely worked around using other techniques — not because the original ideas were bad, but because alternative patterns (redirects, JavaScript) emerged that solved the same problems with more consistent cross-client support.