A 302 redirect and a 307 redirect are both temporary HTTP redirects that tell browsers and search engines a URL has moved to a different location for now, while keeping the original URL intact. Both are treated as temporary redirects by search engines. Both leave the original URL in the search index. Neither transfers SEO equity to the destination.

Like the difference between 301 and 308, the distinction between 302 and 307 comes down to a single technical detail, how they handle the HTTP request method when a browser or client follows the redirect. For standard browser navigation this difference is irrelevant. For application and API contexts it can be critically important.

What they have in common

Both 302 and 307 belong to the 3xx redirect family and signal a temporary move. Both include a Location header pointing to the temporary destination. Both cause browsers to follow the redirect automatically. Both leave the original URL indexed by search engines and do not transfer link juice or ranking signals to the destination. Neither is cached permanently by browsers, giving you full control to change or remove the redirect at any time.

From an SEO perspective, Googlebot and other web crawlers treat 302 and 307 identically, both are temporary signals that leave the original URL as the canonical address.

The single key difference

The only difference between a 302 and a 307 is how they handle the HTTP request method when the redirect is followed.

• A 302 redirect was originally specified to preserve the request method, but browsers universally switched POST requests to GET when following a 302. This behaviour became so consistent and widespread that it is now the de facto standard, even though it contradicts the original specification. In practice, following a 302 will almost always result in a GET request at the destination regardless of what the original request was.

• A 307 redirect was introduced in HTTP/1.1 specifically to address this inconsistency. It strictly requires the browser to preserve the original request method. A POST remains a POST. A PUT remains a PUT. A DELETE remains a DELETE. The request body is also preserved intact. This is a hard requirement of the specification and all modern clients implement it correctly.

Why the 307 was introduced

The 307 exists because of the gap between what the 302 specification said and what browsers actually did.

When HTTP/1.0 introduced the 302, it specified that the request method should be preserved. Browsers ignored this and switched POST to GET, which turned out to be useful behaviour in many scenarios, particularly after form submissions where you want to redirect to a GET confirmation page. But it also meant there was no reliable way to temporarily redirect a POST, PUT, or DELETE request while keeping the method intact.

HTTP/1.1 resolved this by introducing two new codes. The 303 redirect formalised the method-switching behaviour, explicitly telling browsers to follow the redirect with GET regardless of the original method. The 307 filled the opposite gap, explicitly requiring browsers to preserve the original method through the redirect.

Together 303 and 307 replaced the ambiguity of the 302 with two clearly defined behaviours. The 302 remains in widespread use for backwards compatibility and because browsers handle it consistently in practice, even if not strictly to the original specification.

When the difference matters

For standard browser navigation, a user clicking a link or being redirected from one page to another, the method difference between 302 and 307 is completely irrelevant. Browser navigation is always a GET request. There is no method to switch or preserve and both codes behave identically.

The difference becomes important in three main contexts:

• API endpoints: REST APIs rely on a full range of HTTP methods. If an API endpoint needs to be temporarily redirected, during maintenance, a blue-green deployment, or a temporary infrastructure change, a 302 will cause most clients to switch to GET, breaking any POST, PUT, PATCH, or DELETE requests. A 307 ensures the client repeats the original request with the same method and body at the temporary location.

• Webhook endpoints: webhooks are POST requests sent by third-party services carrying event payloads. If a webhook receiver needs to be temporarily redirected, a 307 ensures the POST and its payload are forwarded correctly. A 302 would cause many senders to switch to GET and silently discard the payload.

• Form submissions requiring method preservation: in web applications where a POST submission must temporarily reach a different URL with its data intact, a 307 guarantees this. By contrast, if the goal is to redirect after a POST to a GET confirmation page, a 303 is the correct choice, not a 302 or 307.

302 vs 307 vs 303

These three temporary redirect codes are closely related and worth understanding together.

• A 302 is the original temporary redirect. Broadly compatible, widely used, and in practice switches POST to GET in most browsers. Use it for standard temporary redirects where method handling does not matter and maximum compatibility is a priority.

• A 303 explicitly switches the follow-up request to GET regardless of the original method. Use it when you want to redirect after a POST to a GET page, the Post/Redirect/Get pattern used in form submissions and login flows.

• A 307 strictly preserves the original request method. Use it when you need a temporary redirect that genuinely keeps POST, PUT, PATCH, or DELETE intact through the redirect.

The relationship between them maps cleanly onto intent. If method does not matter, use 302. If you want to switch to GET, use 303. If you want to preserve the method, use 307.

302 and 307 compared to their permanent counterparts

Both 302 and 307 have permanent equivalents that share the same method handling behaviour.

The 301 redirect is the permanent counterpart to the 302, broadly used, permits method switching in practice, correct for the vast majority of permanent page moves. The 308 redirect is the permanent counterpart to the 307, strictly preserves the request method, correct for permanent API endpoint migrations and webhook moves.

Together the four codes form a complete matrix:

Understanding this matrix makes it straightforward to choose the right redirect code for any situation.

Which one should you use

Use a 302 when:

• A page is temporarily unavailable or has moved for a short period

• You are running an A/B test and traffic will return to the original URL

• You are handling a seasonal campaign or promotional redirect

• You need maximum compatibility across all browsers and legacy clients

• Method handling is not a concern for your use case

Use a 307 when:

• A REST API endpoint is temporarily moving and clients use POST, PUT, PATCH, or DELETE

• A webhook receiver endpoint is temporarily redirecting and POST payloads must be preserved

• Your application requires a temporary redirect that strictly preserves the request method

• You are certain all clients in your environment support 307 correctly

When in doubt, use a 302. It has broader compatibility, simpler semantics for most use cases, and is universally understood. The method preservation that 307 provides only matters in specific technical contexts involving non-GET requests.

Quick reference