303 See Other 3xx
The response to the request can be found at a different URL, retrieved specifically using GET.
What does 303 mean?
A 303 See Other response tells the client that the result of the request can be found at a different URL, and — crucially — that this different URL should be retrieved using GET, regardless of what method the original request used. This makes 303 distinct from 301/302/307/308: those are about redirecting to the same kind of operation elsewhere; 303 is specifically "the result of what you just did lives over there, go GET it."
303 is the standardized foundation of the well-known POST/redirect/GET pattern: a client submits a form via POST, the server processes it and responds with 303 pointing to a page showing the result, and the browser follows up with a GET to that page. This prevents the common "are you sure you want to resubmit this form?" browser warning that occurs if a user refreshes a page that was reached via POST.
How a 303 behaves
- It includes a
Locationheader pointing to the result URL - The client should always use GET for the redirected request, regardless of the original method — this is the defining, guaranteed behavior that distinguishes 303 from 302/307
- It's not cached as a permanent rule the way 301/308 are — it represents "the result of this specific operation is over there," not "this URL has permanently moved"
- It explicitly decouples the action (POST) from viewing the result (GET) — refreshing the resulting page (a GET) is always safe, since it's not resubmitting the original POST
Common scenarios
If you're building the API or website:
- After a successful form submission (creating an order, submitting a comment, completing a purchase), redirect to a confirmation/result page using 303 — this ensures refreshing the confirmation page doesn't resubmit the original action
- This is one of the most common, genuinely useful redirect patterns in everyday web development, even though 301/302 get discussed more often in SEO contexts
If you're calling an API:
- Some APIs use 303 after a POST to point to the created/affected resource's representation — though 201 (with a
Locationheader, no redirect) is more common for pure API-to-API interactions; 303 is more associated with browser-based form submissions
If you're a website visitor:
- Every time you submit a form and land on a "thank you" or "order confirmation" page that you can safely refresh without re-submitting — 303 (or a similar redirect) is very likely involved
303 vs 302 vs 307
| 302 Found | 303 See Other | 307 Temporary Redirect | |
|---|---|---|---|
| Method for redirected request | Often becomes GET (not guaranteed) | Always GET (guaranteed) | Same as original (guaranteed) |
| Typical use | General-purpose temporary redirect | "Here's the result of what you did" — POST/redirect/GET | Temporary redirect preserving method/body |
303 is the only one of these three that specifically guarantees the redirected request is a GET — making it purpose-built for "show me the result of that action" scenarios, as opposed to 307's "repeat the exact same kind of request elsewhere."
Real-world examples
The POST/redirect/GET pattern using 303 (or sometimes 302, used loosely for the same purpose) is one of the most widely-implemented patterns in web development — virtually every form-based web application that shows a confirmation page after submission relies on some version of this pattern to ensure page refreshes don't resubmit forms. Some APIs use 303 to point clients from an action endpoint to a representation of the result — useful when the "result" of an operation is better expressed as "go look at this resource" rather than returning the result data directly in the response to the original request.
SEO implications
303 has relatively limited direct SEO significance compared to 301/302, since it's primarily associated with the result of user actions (form submissions) rather than navigable content pages that search engines would prioritize crawling/indexing — the destination of a 303 (a confirmation page) typically isn't the kind of content that benefits from ranking signal transfer in the way a permanently-moved content page would.
FAQ
What's the difference between 302 and 303?
302 doesn't guarantee the redirected request's method — historically, clients have handled this inconsistently. 303 explicitly guarantees the redirected request will be a GET, regardless of the original request's method, making it the more precise choice for "the result of this action is over there, go view it."
What is the "POST/redirect/GET" pattern?
A common web pattern: a form submission (POST) is processed by the server, which responds with a redirect (often 303) to a separate URL representing the result. The browser then makes a GET request to that URL. This means refreshing the result page only re-sends the GET (harmless), not the original POST (which could cause duplicate submissions).
Why does this pattern prevent "resubmit form" warnings?
Because after the redirect, the browser's "current page" was reached via GET, not POST. Refreshing a GET-reached page simply re-requests that GET — there's no POST to potentially resubmit, so browsers don't show the resubmission warning they display when refreshing a page that was directly reached via POST.
Is 303 used for permanent redirects?
No — 303 is about "the result of this specific request is over there," which is inherently tied to this particular request/action, not a statement about the original URL permanently pointing elsewhere. For permanent URL changes, 301/308 remain the appropriate codes.
Can APIs use 303 instead of 201 after creating a resource?
Some do, particularly in browser-facing applications where redirecting to a "view this resource" page makes sense. For pure API-to-API interactions, 201 (with the created resource's data and a Location header, but no redirect) is more common, since API clients typically want the result data directly rather than following a redirect to fetch it separately.
Fun fact
303 is sometimes underappreciated specifically because its most common real-world use (preventing form-resubmission issues) is so seamless that most users — and even many developers — experience its benefits constantly without ever realizing a specific, deliberately-chosen status code is responsible for that "refreshing this page is safe" behavior they've come to expect from well-built websites.