HTTP 303 See Other and POST-redirect-GET
303 See Other tells the client to fetch a different URL with a GET, regardless of the original request method. It is the backbone of the POST-redirect-GET pattern, sending a browser to a result page after a form submission so a refresh does not resubmit. Because it forces GET, it differs from method-preserving 307.
What 303 means
303 See Other instructs the client to retrieve the resource at the URL in the Location header using a GET request, even if the original request used POST or another method. It is specifically designed to redirect the result of an operation to a separate, GET-able URL.
The defining behaviour is the forced method change to GET.
POST-redirect-GET and how it differs from 307
The classic use is POST-redirect-GET: a user submits a form (POST), the server processes it, then responds 303 pointing at a confirmation or result page. The browser GETs that page, so reloading it re-fetches the result rather than resubmitting the form. This avoids duplicate submissions.
Contrast with 307, which preserves the method: following a 307 after a POST would repeat the POST. Use 303 when you want to switch to GET, and 307/308 when the method must be kept.
- 303 — redirect and switch to GET (POST-redirect-GET)
- 307 — temporary redirect, method preserved
- 303 prevents form resubmission on reload
Operator checklist
Use 303 after form submissions to send users to a GET-able result page. Confirm the Location target exists and returns 200. Do not use 303 where the method must be preserved — choose 307 or 308 there. For permanent page moves, use 301/308 instead.
How it appears in analytics and logs
A 303 tells the client to GET another URL, changing the method to GET if it was not already. It usually appears after a write (form POST) directing to a result page; crawlers issuing GETs simply follow it to the target.
Diagnostic use case
Implement POST-redirect-GET after form submissions so reloads do not resubmit, and understand why 303 forces a GET unlike 307.
What WebmasterID can help detect
WebmasterID can show which URLs return 303 to traffic and crawlers, helping you confirm the POST-redirect-GET flow is sending clients to the right result URL.
Common mistakes
- Using 303 for a permanent page move instead of 301/308.
- Expecting 303 to preserve a POST — it forces GET; use 307 to preserve.
- Pointing the 303 Location at a URL that itself errors or redirects.
Privacy and accuracy notes
Redirect status codes carry no personal data. WebmasterID reports redirect patterns for crawler traffic without exposing individual visitors.
Related pages
- HTTP 302 Found (temporary redirect)
302 Found signals a temporary redirect: the resource is briefly available at a different URL, but the original should still be used in future. Because it does not communicate permanence, crawlers keep the original URL. Using 302 for a permanent move is a common diagnostic problem.
- HTTP 307 Temporary Redirect
307 Temporary Redirect is a temporary redirect that, unlike the historically ambiguous 302, guarantees the request method and body are preserved. A POST stays a POST. It signals impermanence, so crawlers keep the original URL while following the detour for the current request.
- Website observability
See which URLs return redirects to your traffic and crawlers.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.