302 vs 307: Found vs Temporary Redirect
302 and 307 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 302 — Found | HTTP 307 — Temporary Redirect |
|---|---|---|
| Definition | The resource is temporarily available at a different URL. Unlike 301, clients should continue using the original URL for future requests. Historically misused — prefer 307 (method-preserving) or 303 (POST/redirect/GET) for more explicit semantics. | Unlike 302, a 307 requires the client to repeat the request to the new URL with the same method and body. Use this when method preservation matters for temporary redirects. |
| Plain-language summary | The resource is temporarily available at a different URL. The original URL remains valid and the client should continue using it for future requests. Unlike 301, browsers do not cache 302 redirects, and search engines do not transfer SEO signals. Historically, browsers changed POST to GET on 302, which is technically incorrect but widely implemented. | Temporary redirect with mandatory method preservation. The client must repeat the request to the Location URL using the same HTTP method and body. If the original was a POST, the repeat must also be a POST. This is the spec-correct version of 302 for cases where method preservation matters. |
| When to use | Use 302 for temporary redirects where the original URL should be preserved. Prefer 307 when you need to guarantee method preservation (POST stays POST). Use 303 for Post/Redirect/Get (PRG) patterns after form submission. Never use 302 for permanent URL changes — that is a 301. | Use 307 when: you need a temporary redirect AND the HTTP method must be preserved (e.g., a POST to /checkout being temporarily routed to /checkout-v2). Use 302 when method preservation does not matter or when you accept the browser's POST→GET behavior. Use 308 for permanent redirects with method preservation. |
| Client behavior | Browsers follow the redirect automatically and typically change POST to GET (historical, widely-implemented non-spec behavior). The redirect is not cached; each visit to the original URL re-checks the server for a redirect. Crawlers visit the original URL again in future crawls rather than updating their index. | Client repeats the full request (same method, same body, same headers) to the Location URL. Browsers prompt for confirmation before re-sending a POST body. Unlike 302, a POST remains a POST. Not cached. |
| Caching behavior | Not cached by default. Each request to the original URL hits the server and may receive a different destination. You can add Cache-Control headers to cache 302s, but this is rarely appropriate for truly temporary redirects. | Not cached by default. Like 302, temporary redirect responses are not stored unless you explicitly add caching headers (rarely appropriate). |
| SEO / crawler impact | Search crawlers interpret 302 (redirect-codes) for indexation and link equity accordingly. | Search crawlers interpret 307 (redirect-codes) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 302 expect Found semantics. | API clients branching on 307 expect Temporary 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 302
Appears in login flows, feature flags, A/B testing, short-term promotional redirects, and geographic routing. Common in access logs during marketing campaigns or seasonal routing. Watch for 302s that have been "temporary" for months — if the destination is permanent, convert to 301 and recover the lost SEO signals.
When you see HTTP 307
Less common than 302 in typical web applications but important in API gateways and service meshes where POST/PUT/DELETE requests need temporary routing changes. Used in HTTPS enforcement where method preservation matters for POST endpoints.
Decision rule
Use 302 when the response should communicate found behavior; use 307 when temporary redirect is the accurate protocol signal.
A frequent mistake is swapping 302 and 307 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 302 when the correct protocol signal is Found. Use 307 when the correct signal is Temporary Redirect. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 302 and 307?
302 communicates Found, while 307 communicates Temporary Redirect. Choosing the right one keeps clients and intermediaries predictable.
Do 302 and 307 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 302 instead of 307?
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 302 Found — full guide · HTTP 307 Temporary Redirect — full guide · All comparisons · HTTP 302 status reference · HTTP 307 status reference