Skip to main content

What Is the Difference Between 301, 302, 307, and 308 Redirects?

301 and 308 describe permanent redirects; 302 and 307 describe temporary redirects. The crucial method difference is that 307 and 308 require the client to preserve the request method, while historical handling of 301 and 302 may change a POST into a GET.

Use the HTTP Status Code Reference to compare redirect definitions, then verify the real response with a client that shows each hop, method, Location header, and cache behavior.

Choose a redirect from permanence and method behavior

StatusMeaningMethod on automatic follow
301 Moved PermanentlyPermanent replacementPOST may become GET for historical compatibility
302 FoundTemporary alternate locationPOST may become GET for historical compatibility
307 Temporary RedirectTemporary alternate locationMethod and body must be preserved
308 Permanent RedirectPermanent replacementMethod and body must be preserved

Permanence and method behavior are separate decisions

Choose permanent or temporary based on the resource relationship, not on which code is most familiar. A permanent redirect tells clients and intermediaries that the target should replace the original reference. A temporary redirect keeps the original URI meaningful because the target may change or the condition may end.

Then decide what must happen to the request method and body. Status 307 and 308 explicitly prohibit changing the method when automatically following the redirect. For 301 and 302, user agents may change a POST request to GET for historical compatibility. Status 303 explicitly directs the client to retrieve another resource with GET or HEAD and is often appropriate after a successful form submission.

Test the chain instead of trusting configuration labels

Inspect the actual status and Location header at every hop. A proxy, CDN, framework, authentication layer, or slash-normalization rule can add another redirect before the application response. Test GET, HEAD, and any authorized non-safe method separately because a browser navigation does not prove what an API client will do with a body.

For a site migration, link directly to the final canonical URL, update sitemaps and canonicals, avoid loops and long chains, and keep the old-to-new mapping stable. A redirect can consolidate a moved URL, but it cannot repair a destination whose content does not satisfy the original user intent.

Verify the redirect as a complete request flow

  • Decide whether the move is permanent and whether the original method and body must be preserved.
  • Use an absolute or correctly resolved Location value and reject open-redirect destinations.
  • Test each hop without automatic following, then test the complete chain with representative clients.
  • Update internal links, canonicals, and sitemaps to the final URL instead of relying on redirects internally.

A method-preserving maintenance redirect

A conforming client that follows this 307 sends POST to the target with the request body preserved. If the intended next action were a safe results page after processing, a 303 response would express a different workflow.

POST /v1/jobs HTTP/1.1

HTTP/1.1 307 Temporary Redirect
Location: https://api.example.com/v2/jobs

Redirect choices that change requests unexpectedly

  • Do not use 301 for an experiment or short outage merely because browsers follow it; permanent responses can be cached.
  • Do not assume a POST remains POST after 301 or 302 across every client.
  • Do not reflect an arbitrary next or return URL without validating its scheme, host, and allowed destination.

Use the decision in context

Apply the choice with the HTTP Status Code Reference. Explore the technical reference collection for related tasks.

HTTP redirect status questions

Should a trailing-slash redirect use 301 or 308?

Either can express a permanent canonicalization. Use 308 when method preservation is required; test framework and client behavior before changing an established contract.

Does a permanent redirect guarantee Google will index the target?

No. It is a strong consolidation signal, but the destination still needs to be crawlable, indexable, canonical, useful, and relevant to the original URL.

Standards to check before deciding