307 Temporary Redirect 3xx

What does 307 mean?

A 307 Temporary Redirect is functionally similar to 302 — it tells the client the resource is temporarily at a different URL, and the original URL remains canonical — but with one critical, spec-guaranteed difference: the HTTP method and body of the original request must be preserved when following the redirect.

307 exists specifically to remove the ambiguity that 302 carries. If a client sends a POST request and receives a 302, different clients have historically handled this differently — some resend the redirected request as a POST (preserving the body), others convert it to a GET (dropping the body). A 307 leaves no room for that ambiguity: clients must repeat the request with the same method and body at the new location.

How a 307 behaves

• It includes a Location header pointing to the temporary URL, same as 302
• The method is guaranteed to be preserved — a POST redirected via 307 must be followed up with another POST (including the same body) to the new URL
• It's not cached long-term — like 302, it represents a temporary state
• Search engines treat it like 302 — the original URL remains canonical; ranking signals don't transfer to the redirect target
• It's relatively uncommon in everyday browsing — most page-level redirects use 301/302 since they're GET requests anyway (where method preservation doesn't visibly matter); 307 becomes important specifically for non-GET requests

Common causes

If you're building the API or website:

• You need to temporarily redirect a non-GET request (POST, PUT, DELETE) to a different endpoint while guaranteeing the method and payload aren't altered — e.g., temporarily routing form submissions to a different backend during a migration
• A load balancer or API gateway is temporarily redirecting traffic to a different backend service, and requests include bodies that must arrive intact
• HTTPS upgrade redirects sometimes use 307 (or 308) specifically so that POST requests being upgraded from HTTP to HTTPS don't lose their body

If you're calling an API:

• An API endpoint is temporarily redirecting requests (including POST/PUT bodies) to an alternate location, perhaps during a backend migration or incident response
• You're working with an HTTP client library and need to confirm it correctly preserves method/body on 307 — most modern, spec-compliant libraries do, but it's worth verifying for older or custom clients

If you're a website visitor:

• You generally won't notice 307s directly — they primarily affect non-GET requests (form submissions, API calls triggered by JavaScript), which don't have a visible "redirect" the way page navigation does

How to fix it / use it correctly

As an API/website builder:

• Use 307 (instead of 302) whenever you need a temporary redirect for a non-GET request and must guarantee the body/method survive
• For permanent redirects of non-GET requests where method preservation matters, use 308 instead (308 is to 307 what 301 is to 302 — permanent vs temporary, both with guaranteed method preservation)
• Don't use 307 for simple page-to-page navigation redirects where 301/302 already work fine — 307 adds value specifically when method preservation is the concern

As an API consumer:

• If your client library doesn't seem to follow 307 redirects correctly (e.g., it's converting your POST to a GET), check whether it's spec-compliant — most modern libraries (recent versions of curl, fetch, axios, etc.) handle 307 correctly by design
• Be aware that following a 307 means resending your full request body to a new URL — if that body is large or contains sensitive data, make sure the redirect target is trusted (same security considerations as any redirect involving sensitive payloads)

As a website visitor:

• Nothing to do — this operates transparently at the HTTP client level

301 vs 302 vs 307 vs 308

Real-world examples

Some HTTPS-upgrade configurations use 307 (or 308) specifically to ensure that form submissions made over HTTP — which arrive as POST requests with a body — aren't silently converted to GET requests (and thus lose their data) when redirected to the HTTPS version of the same endpoint. API gateways performing temporary backend migrations sometimes use 307 to redirect specific routes to a new service while a migration is in progress, relying on the guarantee that POST bodies will arrive intact at the new destination.

SEO implications

307 is treated the same as 302 for SEO purposes — the original URL remains canonical, and ranking signals don't transfer to the redirect destination. Since 307 is primarily relevant to non-GET requests (which search engine crawlers generally don't make — crawlers issue GET requests when indexing pages), 307 has minimal direct relevance to typical page-level SEO compared to 301/302.

FAQ

What's the actual difference between 302 and 307?

Functionally, both indicate a temporary redirect where the original URL stays canonical. The difference is that 307 guarantees the HTTP method and request body are preserved when the client follows the redirect, while 302 historically does not guarantee this — some clients convert a POST to a GET when following a 302.

Do I need to worry about 307 for normal page links?

Not really. Page navigation is done via GET requests, and for GET requests, "method preservation" isn't a meaningful concern (a GET redirected to a GET is the same either way). 307 matters specifically for POST, PUT, DELETE, and similar requests with bodies.

Why would a client convert POST to GET on a redirect at all?

This goes back to early HTTP implementations and differing interpretations of the original (somewhat ambiguous) 302 specification. Some browsers/clients adopted the convention of always issuing a GET for the redirected request regardless of the original method, and this behavior persisted for backward compatibility even after the spec was clarified — which is exactly why 307 and 308 were introduced as unambiguous alternatives.

Is 307 commonly used for normal websites?

Less commonly than 301/302, since most everyday redirects involve GET requests where method preservation isn't a visible concern. 307 is more relevant in API contexts, form-handling edge cases, and infrastructure-level redirects involving non-GET methods.

If I switch from 302 to 307, will anything break?

For GET requests, no — behavior is effectively identical. For non-GET requests, switching from 302 to 307 means clients are now guaranteed (rather than merely likely) to resend the original method and body — if your redirect target isn't prepared to receive, say, a POST with a body it wasn't expecting, that could surface issues that were previously masked by clients converting to GET.

Fun fact

307 and 308 are sometimes called the "strict" versions of 302 and 301 — they don't change what the redirect means (temporary vs. permanent) but instead close a long-standing ambiguity gap in the original specifications, making them a good example of how HTTP evolves by adding more precise versions of existing concepts rather than replacing them outright — both old and new codes remain valid and in use today.