A 307 redirect is a temporary HTTP status code that tells a browser to repeat its request at a new URL while preserving the original HTTP method. If the original request was a POST, the browser sends a POST to the new location. If it was a GET, it sends a GET. The method never changes.

It belongs to the 3xx redirect family and was introduced in HTTP/1.1 alongside the 303 redirect to resolve the ambiguity that had built up around the 302 redirect and how browsers handled method preservation in practice.

How a 307 redirect works

When a server responds with a 307, it includes a Location header pointing to the new URL. The browser follows the redirect immediately, but unlike a 302 or 303, it must use exactly the same HTTP method and send the same request body it used originally.

This strict method preservation is the defining characteristic of the 307. It is not optional or browser-dependent, it is a hard requirement of the HTTP specification. A browser or client that changes the method when following a 307 is not compliant with the standard.

Why the 307 was introduced

The 307 exists because of a long-standing inconsistency in how browsers handled 302 redirects.

The original HTTP/1.0 specification said browsers should preserve the request method when following a 302. In practice, every major browser ignored this and switched POST requests to GET when following a 302. This became so widespread that it was effectively the expected behaviour, even though it contradicted the spec.

HTTP/1.1 addressed this by introducing two new codes to replace the ambiguous 302 for specific use cases. The 303 was introduced for situations where switching to GET is explicitly intended. The 307 was introduced for situations where preserving the original method is explicitly required. Together they eliminated the ambiguity that the 302 had accumulated over years of inconsistent browser behaviour.

307 redirects and SEO

Like the 302 and 303, the 307 is treated as a temporary redirect by search engines. This means search engines keep the original URL in their index and do not transfer SEO equity or link juice to the destination URL.

If you are managing redirects for SEO purposes, moving pages permanently, migrating a domain, consolidating URLs, the 307 is not the right tool. Use a 301 redirect for permanent moves. The 307 belongs in application and API logic where method preservation matters, not in URL management for search visibility.

When to use a 307 redirect

The 307 is used primarily in scenarios where the HTTP request method carries meaning that must be preserved through the redirect. The most common use cases are:

• API endpoints: if a REST API endpoint has temporarily moved and incoming POST, PUT, PATCH, or DELETE requests need to be redirected to the new location without losing their method or body, a 307 ensures the client repeats the exact same request at the new URL.

• Form submissions requiring method preservation: in web applications where a POST request must remain a POST after a temporary redirect, a 307 guarantees this across all compliant clients. This is in contrast to a 303, which would switch the follow-up request to GET.

• Temporary infrastructure changes: during server maintenance or load balancing changes where requests need to be routed temporarily to a different endpoint while preserving the full request, a 307 handles this correctly.

• HTTPS enforcement: some web servers use 307 rather than 301 when redirecting HTTP to HTTPS because 307 is temporary and does not get cached permanently by browsers. This gives server administrators more flexibility to change the configuration later, though in most cases a 301 or HSTS is the preferred approach for permanent HTTPS enforcement.

307 vs 302 and 303

These three codes are closely related and understanding the differences between them is important for using each correctly.

• A 302 redirect is the original temporary redirect. Despite the specification saying method should be preserved, browsers switch POST to GET in practice. Use a 302 when you need broad compatibility and the method switch does not matter for your use case.

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

• A 307 redirect strictly preserves the original method. Use a 307 when you need the client to repeat the exact same request, same method, same body, at a new temporary location. This is the semantically correct choice for temporary redirects in API contexts.

307 vs 308

The 308 redirect is to 307 what 301 is to 302. A 307 is temporary, search engines keep the original URL indexed and the redirect is expected to end at some point. A 308 is permanent, it signals the resource has moved forever while still preserving the request method.

If you need permanent method-preserving redirects, use a 308. If the move is temporary, use a 307.

Common mistakes with 307 redirects

• Using 307 for permanent moves: because the 307 is temporary, search engines will not pass SEO equity to the destination and will keep indexing the original URL. If a move is permanent, always use a 301 or 308.

• Using 307 when 303 is intended: if the goal is to redirect a POST to a GET confirmation page, a 303 is the correct choice. Using a 307 in this scenario would cause the browser to POST to the confirmation page, which is almost certainly not the intended behaviour.

• Assuming 307 behaviour from 302: if your application relies on method preservation and you are using a 302 expecting browsers to preserve the method, you cannot rely on this. Switch to a 307 to guarantee the behaviour across all compliant clients.

• Creating redirect chains: as with all redirect types, chaining multiple 307s adds latency and creates unnecessary complexity. Always redirect directly to the final destination and audit for redirect chains regularly.