HTTP status · 3xx — redirection
303 See Other
303 tells the client to fetch another URL with GET, usually after a form submission.
Key facts
| Class | 3xx — redirection |
|---|---|
| Standard | RFC 9110 §15.4.4 |
| Method after redirect | GET (HEAD stays HEAD) |
| Location header | Required |
| Cacheable | No, by default |
| Typical use | Post/Redirect/Get |
303 always ends in a GET
Unlike 301 and 302, the method change is part of the definition: the client follows the Location with GET, even if the original request was a POST. That makes 303 the correct answer to a successful form submission that should not be re-submitted when the user refreshes.
The response itself has no body. If a client does not follow redirects, it receives the Location URL and must decide what to do next.
303 in the Post/Redirect/Get pattern
A form posts to an endpoint; the server writes the data and answers 303 See Other with a link to a confirmation page. The browser follows with GET, so reloading the confirmation does not repeat the write. This is the safest default for any mutation that a human can trigger twice.
Frequently asked questions
What is the difference between 302 and 303?
302 is historical and inconsistent about method changes. 303 explicitly requires a GET, which makes it the safe choice after a POST.
Does 303 mean the resource moved permanently?
No. It is a temporary, request-specific instruction to fetch another URL.
Should a 303 response be cached?
Not by default. Caching a 303 can cause clients to skip the state change on later requests.