303 vs 308: See Other vs Permanent Redirect
303 and 308 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 303 — See Other | HTTP 308 — Permanent Redirect |
|---|---|---|
| Definition | Used after a POST to redirect the user to a result page. Prevents form resubmission on browser reload. This is the Post/Redirect/Get (PRG) pattern. | Like 301, this signals a permanent move. Unlike 301, the HTTP method must be preserved (a POST stays a POST). Defined in RFC 7538. |
| Plain-language summary | HTTP 303 See Other redirects the client to retrieve the response from a different URL using GET, regardless of the original method. | Permanent redirect with mandatory method preservation. Like 301, signals a permanent move that crawlers and clients should update their records for. Like 307, requires the client to preserve the HTTP method. The correct choice when you need both permanence and method preservation. |
| When to use | HTTP 303 See Other redirects the client to retrieve the response from a different URL using GET, regardless of the original method. | Use 308 when: the move is permanent AND the HTTP method must be preserved (POST stays POST). Use 301 for permanent moves where method preservation is not required (GET-based navigation, page moves). Use 307 for temporary moves with method preservation. |
| Client behavior | Client handles 303 according to redirect-codes semantics. | Client repeats the full request to the Location URL with the same method and body, and updates its internal records (bookmarks, cached redirect). Crawlers follow and transfer SEO signals to the destination. Unlike 301, POST does not become GET. |
| Caching behavior | See 303 caching spec. | Cached by browsers and crawlers like 301. The redirect is permanent and clients should not revisit the original URL. |
| SEO / crawler impact | Search crawlers interpret 303 (redirect-codes) for indexation and link equity accordingly. | Search crawlers interpret 308 (redirect-codes) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 303 expect See Other semantics. | API clients branching on 308 expect Permanent Redirect semantics. |
| Safe to retry? | Follow redirect, then retry original intent | Follow redirect, then retry original intent |
Common real-world scenarios
When you see HTTP 303
303 appears in production when: Resource moved to a different URI; Canonicalization or routing rule.
When you see HTTP 308
Used in API versioning (permanently moving POST /api/v1/orders to /api/v2/orders), HTTPS enforcement where POST endpoints are involved, and service architecture migrations where method semantics must be preserved end-to-end.
Decision rule
Use 303 when the response should communicate see other behavior; use 308 when permanent redirect is the accurate protocol signal.
A frequent mistake is swapping 303 and 308 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 303 when the correct protocol signal is See Other. Use 308 when the correct signal is Permanent Redirect. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 303 and 308?
303 communicates See Other, while 308 communicates Permanent Redirect. Choosing the right one keeps clients and intermediaries predictable.
Do 303 and 308 have SEO or caching impact?
Yes. Search engines and caches interpret status classes differently. Use each code according to its semantics to avoid accidental indexing, stale responses, or crawl inefficiency.
Can APIs safely return 303 instead of 308?
Only when it matches contract semantics. API clients often branch logic by exact code, so swapping them can break retries, auth handling, or user-facing errors.
Full guides
HTTP 303 See Other — full guide · HTTP 308 Permanent Redirect — full guide · All comparisons · HTTP 303 status reference · HTTP 308 status reference