What Is 307 Redirect?

Why It Matters

The 307 status code was introduced in HTTP/1.1 to fix an ambiguity in the 302 redirect. With a 302, browsers are technically allowed to change the HTTP method — a POST request might be replayed as a GET after the redirect. In practice, most browsers do change POST to GET on a 302.

A 307 guarantees the method stays the same. This matters for form submissions, API calls, and any non-GET request that gets redirected. If a user submits a form and the endpoint returns a 307, the browser resends the form data to the new URL as a POST — not as a GET that loses the data.

How It Works

The server responds with:

• HTTP Status Code 307 (Temporary Redirect)
• A Location header pointing to the new URL

The browser follows the redirect using the same HTTP method as the original request. POST stays POST, PUT stays PUT, DELETE stays DELETE.

Common Mistakes

Using 307 for permanent moves. A 307 is temporary — search engines won’t transfer link equity. For permanent redirects that preserve the HTTP method, use 308 instead.

Confusing 307 with 302. They both signal temporary moves, but 307 is stricter about preserving the HTTP method. For domain forwarding (which handles GET requests), the distinction rarely matters. It matters for APIs and form endpoints.

How Domain Forward Handles This

Domain Forward supports 301 and 302 redirect types. Since domain forwarding handles browser GET requests, 307/308 are less commonly needed. For API-level redirect control, use Domain Forward’s REST API.