301 vs 302 vs 307 vs 308: choosing an HTTP redirect

Start with two decisions

A redirect tells a client to look at another URL. Before choosing a code, decide whether that move is permanent and whether the next request must keep the original method and body. A page view and an API submission can need different treatment even when both move to the same destination.

A 303 See Other serves another purpose: directing the client to retrieve a different resource, commonly a confirmation page after a form submission. Do not substitute 307 merely because it sounds newer. The intended follow-up request matters. See MDN’s redirect guide.

Worked example: an address change versus a submission

Suppose /help/old-name has permanently become /help/new-name. A 301 is a reasonable choice for ordinary GET visits. Update your own navigation to point directly to the new address, while keeping the redirect for bookmarks and external links. Check that the final page exists before publishing the rule.

Now suppose a client submits POST /api/estimate with a JSON body, and that endpoint temporarily moves to /api/estimate-v2. If the destination expects the same submission, 307 expresses that intent. With 302, a client could turn the follow-up into GET, leaving the destination without the expected body.

Illustrative exchange, not a live endpoint:
POST /api/estimate
→ 307 Temporary Redirect
  Location: /api/estimate-v2
→ POST /api/estimate-v2

Test with the actual client used by your application. Do not test a payment or other state-changing operation by repeatedly submitting a real transaction. Use a controlled test account and data that cannot trigger production effects.

Investigate a chain one hop at a time

1. Open the browser Network panel and preserve the log before reproducing the navigation. Record the starting URL, method, and time.
2. For each redirect, inspect the status and Location response header. Follow the sequence to the final response.
3. Look for repeated URLs, HTTP-to-HTTPS reversals, or competing trailing-slash rules. A loop often spans more than one configuration layer.
4. Export a sanitized HAR if you need to compare the request sequence later. In the HAR Viewer, select a row to inspect its recorded headers and details.
5. After changing a rule, check both a clean browser session and the affected client. Previously stored redirects can make old behavior appear to persist.

A useful investigation note might read: “GET old address → 301 secure address → 302 login → 200 login form.” That is much more informative than “the page returned 200,” because the final success response may belong to a different page.

Common mistakes

• Calling every redirect an error. A deliberate move may be working exactly as intended. Investigate when the destination, method, or number of hops is unexpected.
• Changing several rules together. Adjust one layer, record the result, then move on. Otherwise it becomes difficult to identify the rule responsible.
• Assuming a redirect guarantees search visibility. It is a routing signal, not a promise about indexing or rankings.
• Trusting a redirect destination automatically. Check the hostname before entering credentials. A redirect does not establish the destination’s trustworthiness.

What the tools can tell you

The status reference explains a code; it does not inspect your server. The HAR Viewer shows an exported capture, so missing requests or stripped headers remain missing. A certificate check can help when the destination fails during TLS setup, but it does not validate redirect rules. Use these results to decide which server logs or configuration to examine next.

Sources and review

• HTTP semantics: redirect codes
• MDN: redirects
• Chrome: Network panel and HAR export

Examples are illustrative. Reviewed September 28, 2026 against the sources above and the related tool interfaces. Editorial methodology · Report a correction.