Redirection
303

See Other

The server redirects the client to a different URI using a GET request, typically after a POST form submission.

# Quick Definition

The 303 See Other status code tells the client that the response to the request can be found at a different URI and should be retrieved using a GET method. Unlike 301 or 302, the 303 explicitly changes the request method to GET regardless of what the original method was. This makes it the correct choice for redirecting after POST form submissions.

# When Does a 303 Redirect Occur?

A 303 redirect most commonly occurs as part of the Post-Redirect-Get (PRG) pattern. After a user submits a form via POST, the server processes the data, then responds with a 303 redirect pointing to a confirmation or results page. The browser follows the redirect using GET, which means refreshing the resulting page won't re-submit the form.

This pattern solves the classic "double submission" problem where users accidentally submit forms twice by refreshing the page or clicking the back button. The 303 ensures the browser's history contains a safe GET request rather than a repeatable POST.

# Common Use Cases

# Best Practices

  1. Always use 303 for POST-to-GET redirects -- While 302 often works in practice (browsers typically change POST to GET), 303 is the semantically correct choice and guarantees the method change.
  2. Set the Location header correctly -- The Location header must contain the full or relative URI the client should follow. Ensure it points to a valid, accessible resource.
  3. Process the data before redirecting -- Complete all server-side processing (database writes, email sends, etc.) before sending the 303 response. The redirect means the POST data is gone.
  4. Use flash messages for feedback -- Since the redirect loses the POST context, store success/error messages in the session (flash messages) to display on the redirected page.
  5. Don't use 303 for permanent URL changes -- If a resource has permanently moved, use 301 or 308 instead. Reserve 303 for functional redirects where the method should change to GET.

# HTTP Example

Request (Form Submission)
POST /orders HTTP/1.1
Host: shop.example.com
Content-Type: application/x-www-form-urlencoded

product=widget&qty=2&payment=card
Response
HTTP/1.1 303 See Other
Location: /orders/confirmation?id=ord_789
Browser Follows Redirect
GET /orders/confirmation?id=ord_789 HTTP/1.1
Host: shop.example.com

# Related Status Codes

# Frequently Asked Questions

What is the difference between 303 and 302?+
Both 303 and 302 are redirect status codes, but they differ in method handling. A 303 See Other explicitly requires the client to use GET when following the redirect, regardless of the original request method. A 302 Found technically should preserve the original method, though most browsers change POST to GET anyway. Use 303 when you specifically want the redirect to always use GET, such as after a form submission.
What is the Post-Redirect-Get (PRG) pattern?+
The Post-Redirect-Get (PRG) pattern is a web development design pattern that prevents duplicate form submissions. After a user submits a form via POST, the server processes the data and responds with a 303 redirect to a results page. The browser then makes a GET request to the redirect URL. If the user refreshes the page, only the GET request is repeated, not the original POST, preventing duplicate orders, payments, or data entries.
Does 303 affect SEO?+
A 303 See Other redirect does not pass SEO value (link equity) because it is a temporary redirect by nature. Search engines understand that 303 is used for functional redirects (like after form submissions) rather than permanent URL changes. For SEO-related URL changes, use 301 (permanent) or 308 (permanent with method preservation) instead.

Verify your redirects are working

Monitor redirect chains, detect broken links, and ensure your forms redirect correctly.

Start Free Monitoring