HTTP 303 See Other
HTTP 303 See Other tells the client to retrieve a different resource using GET, regardless of what method was used in the original request. Unlike 302, which inadvertently became a method-changing redirect due to browser behavior, 303 explicitly and intentionally changes the request method to GET when following the redirect.
Quick reference
| Code | 303 |
|---|---|
| Name | See Other |
| Category | 3xx Redirect |
| Specification | RFC 9110 §15.4.4 |
| IANA status | Assigned |
| Cacheable | No — not cacheable |
| Client action | Follow the Location header with a GET request regardless of the original method. |
| In-depth guide | HTTP 303 full guide → |
What HTTP 303 means
RFC 9110 defines 303 as indicating that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location field, which is intended to provide an indirect response to the original request. The user agent must follow the redirect using GET regardless of the method used in the original request.
The "regardless of method" clause is the defining characteristic. A 303 after a POST explicitly tells the client: the POST was processed; now GET this URL to see the result. This is the formal mechanism for the Post/Redirect/Get pattern, one of the most important patterns in web application design.
Post/Redirect/Get pattern
The classic problem 303 solves: a user submits a form (POST). The server processes it and returns a page. If the user hits the browser's back button and reloads, the browser re-submits the form. This causes duplicate orders, duplicate registrations, duplicate payments.
The 303 solution: process the POST, then return 303 to a results page URL. The browser follows the 303 with a GET to the results page. Now the browser's current page is the GET results page. Reloading re-GETs the results page, not re-POSTs the form.
POST /checkout → 303 See Other → Location: /order/54321/confirmation GET /order/54321/confirmation → 200 OK (order confirmation page)
This is the standard pattern for any form submission in server-rendered web applications.
303 vs 302 vs 307
| Code | Method after redirect | Permanent? | Use when |
|---|---|---|---|
| 302 | GET (in practice, not RFC) | No | Temporary redirect, method change acceptable (historical) |
| 303 | GET (explicitly by RFC) | No | POST processed, redirect client to GET result page |
| 307 | Same as original | No | Temporary redirect, must preserve method |
Use 303 explicitly when you want to redirect after a POST to a GET-able result page. Use 307 when you need to redirect a POST to another POST endpoint while preserving the method and body.
FAQ
What does HTTP 303 See Other mean?
HTTP 303 means: the server processed your request and is redirecting you to GET a different URL for the response. The method always becomes GET after a 303, regardless of what method the original request used.
When should I use 303 instead of 302?
Use 303 when you explicitly want the method to change to GET — typically after processing a POST form submission. 302 has the same effect in practice (browsers change POST to GET), but 303 is the explicit, RFC-compliant way to signal a POST-to-GET redirect.
Does 303 preserve the request body?
No. The method becomes GET and GET requests have no body. The redirect is to a URL that the client should GET to retrieve the response to the original operation.
Is 303 cached?
No, not by default. 303 does not carry cache semantics like 301. The redirect is followed fresh on each visit to the original URL.
Related resources
On this site: HTTP 303 See Other — full guide · HTTP 302 Found · HTTP 307 Temporary Redirect · HTTP 301 Moved Permanently · All 3xx redirect codes
Comparisons: 302 vs 303 · 303 vs 307
Standards: RFC 9110 §15.4.4 · IANA HTTP Status Code Registry · MDN Web Docs: 303