HTTP 307 Temporary Redirect vs 302: What Changes and Why

Aug 09, 2026 · HTTP Status Codes

The bug report said "checkout form randomly loses all data." It wasn't random. The payment endpoint had moved temporarily behind a redirect, the redirect was a 302, and the browser was following it by converting the POST into a GET — silently dropping the entire form body on the floor. The customer landed on an empty checkout page and started over. The fix was changing one number in a config file: 302 became HTTP 307.

That one behavioral guarantee — the request method survives the redirect — is the whole reason 307 exists.

Why the 307 status code exists at all

The original HTTP spec said clients shouldn't change the method when following a 302. Browsers ignored that from day one and turned redirected POSTs into GETs, because that's what users seemed to want for page navigation. Rather than fight a decade of entrenched behavior, the spec authors formalized reality: 302 permits the method switch, and two new codes were minted with strict semantics. 307 Temporary Redirect forbids changing the method; 308 Permanent Redirect does the same for permanent moves.

So the redirect family splits along two axes — permanence and method handling. A 307 says: this resource is temporarily elsewhere, and whatever you were about to do here (POST, PUT, DELETE, anything), do exactly that over there. Body, method, everything intact.

The 307 you see every day without noticing

Open Chrome DevTools, load a site with HSTS (HTTP Strict Transport Security), and request the plain-HTTP version. You'll see 307 Internal Redirect in the network tab — but no request ever left your machine. Chrome fabricates this synthetic 307 to represent its internal decision to upgrade the connection to HTTPS before touching the network. Your server never saw the HTTP request, and no real 307 was served.

This trips up a lot of debugging sessions. If you're auditing your HTTP-to-HTTPS redirects and you see a 307 in the browser, check with curl before concluding anything about your server config:

curl -sI http://example.com/ | head -3

curl doesn't implement HSTS preload, so it shows you the genuine redirect your server sends — usually a 301.

Watching method preservation in action

Here's a test that makes the 302/307 difference visible. Send a POST through each redirect type and watch what arrives. With a 302 in the middle:

curl -sL -X POST -d "amount=100" https://example.com/pay -o /dev/null -w "%{method} %{url_effective}"

Recent curl versions report the final method — through a 302 you'll typically see it arrive as GET with the body gone, while through a 307 it arrives as POST with the body intact. If your API clients complain about empty request bodies after you moved an endpoint, this is the two-minute test that finds it.

Choosing between 307 and 302

For ordinary page navigation — a user clicking a link, a crawler fetching HTML — GET in, GET out, and the distinction never fires. Use whichever your platform emits; a 302 is fine. The decision matters exactly when non-GET requests can hit the redirected URL:

• Form handlers moved temporarily — a POST that becomes a GET loses its payload. 307 keeps the submission alive.
• API endpoints during maintenance or migration windows — clients sending PUT or DELETE must not have those quietly downgraded.
• Webhooks — payment providers and integrations POST to your URLs. If you temporarily reroute a webhook receiver with a 302, some senders' HTTP libraries will retry as GET and your handler will never see the data.

The rule of thumb I give teams: if the redirected URL only ever receives GETs, 302 and 307 are interchangeable. If anything POSTs to it, 307 is the only safe temporary redirect.

What a 307 means for SEO

Search engines treat 307 like any temporary redirect: the original URL stays in the index, ranking signals stay attached to it, and the destination is treated as a stand-in. Google has said 307 and 302 are handled equivalently for indexing. The same caveat applies too — a "temporary" redirect left in place for months eventually gets treated as permanent, index entry and all.

One thing 307 won't do is transfer signals for a permanent move. If the content has moved for good and you want the new URL to inherit the rankings, you need a 301 or 308. I've seen sites stuck with the wrong URL ranking for over a year because a "temporary" 307 was really a permanent move nobody relabeled.

Finding and fixing unexpected 307s

When a 307 shows up where you didn't put one, work through the layers in order. First separate synthetic from real: if it only appears in the browser and curl shows something else, it's HSTS, not your server. If curl confirms a genuine 307, check your CDN's redirect rules — several platforms emit 307 for their generic "forwarding" features — then your load balancer (AWS ALB redirect actions are configurable between 301 and 302, but some frameworks behind it default to 307 for trailing-slash normalization), then the application itself.

To catch these across a whole site instead of one URL at a time, run a crawl that reports every redirect with its exact status code and scan the 3xx list. A 307 on a URL whose move is permanent, or sitting in the middle of a chain of mixed redirect types, is worth relabeling — mixed chains make your intent ambiguous to every crawler that walks them.