Home >Blog

HTTP Redirect Status Codes: 301, 302, 303, 307, and 308 Explained

Published 2026/09/10Updated 2026/09/10

What HTTP redirect status codes tell the client

An HTTP redirect is a response that says, “the resource you requested is available at another URL.” The server supplies that destination in the Location header, and the client decides whether to follow it. The three-digit status code is not decoration. It tells browsers, crawlers, API clients, and caches whether the move is permanent, whether the next request should use a different method, and how much of the original request can safely be repeated.

That distinction matters most when a request is not a simple page view. A browser can usually replay a GET without much drama. Replaying a POST, PUT, or PATCH can create a duplicate order, lose a request body, or send data to an endpoint that was never meant to receive it. Choose the redirect code according to the request you are moving, not just according to whether the destination “looks right.”

HTTP redirect status codes quick reference

Status	Permanent?	Method and body behavior	Typical use
301 Moved Permanently	Yes	Historically, clients may change POST to GET. Do not rely on the original method or body being preserved across every client.	Permanent page URL changes, domain moves, and canonical HTTP-to-HTTPS redirects when the request is normally a GET.
302 Found	No	Historically, clients may change POST to GET. Behavior is less predictable for non-GET requests.	Temporary routing, experiments, or short-lived maintenance redirects for ordinary browser navigation.
303 See Other	No	The follow-up request should use GET or HEAD, so the original method and body are not carried forward.	Post/Redirect/Get after a form submission, especially when the client should retrieve a result page.
307 Temporary Redirect	No	The client must preserve the original method and request body when following the redirect.	Temporary API routing, failover, or maintenance where POST, PUT, PATCH, or another method must reach the next URL unchanged.
308 Permanent Redirect	Yes	The client must preserve the original method and request body on the permanent destination.	Permanent API endpoint moves or permanent URL changes where method and body preservation are required.

The table is a practical guide, not a substitute for testing the actual client. Older browsers, libraries, proxies, and framework defaults can still introduce surprises. When a redirect carries data, verify the complete exchange rather than assuming that a standards-compliant response guarantees identical behavior everywhere.

301 Moved Permanently

A 301 says that the requested resource has a new permanent URL. Use it for a durable content move: changing a slug, consolidating duplicate pages, moving from an old domain to a new one, or redirecting an old file extension to the current version. Search engines generally treat it as a strong signal to transfer the old URL’s indexing and ranking signals to the target, provided the destination is relevant and the redirect is not part of a manipulative chain.

The awkward part is history. The original definition did not clearly require a client to preserve the method and body, and many clients developed the familiar behavior of turning a redirected POST into a GET. That behavior is often harmless for a normal website link, but it is risky for an API request. A permanent redirect from /checkout to a new endpoint could therefore discard the submitted body or change the operation’s meaning.

Use 301 when the request is a normal page retrieval or when you have explicitly tested the client behavior. If the permanent move must preserve POST, PUT, or PATCH, 308 is usually the clearer choice.

302 Found

A 302 describes a temporary situation. The resource is currently available somewhere else, but the original URL should remain the public address. It is common for short-term routing, an experiment, a temporary campaign destination, or a maintenance page that will be removed soon.

Like 301, 302 has a long history of clients changing a POST into a GET. Modern specifications distinguish 302 from 303 and 307, but real systems still contain old assumptions. For a browser navigating from a link, that rarely causes a visible problem. For an API call, it can be a serious one. If the method and body must survive, use 307 instead.

A 302 can also be cached or remembered in ways that make a temporary test harder to undo than expected, depending on response headers and the client. Avoid using it for a permanent migration simply because it “works in the browser.” That leaves search engines and future maintainers with the wrong message.

303 See Other and the Post/Redirect/Get pattern

A 303 is intentionally different: it tells the client to fetch another resource with GET or HEAD. The usual pattern is Post/Redirect/Get, often shortened to PRG.

Imagine a visitor submits a contact form with POST /contact. The server validates the submission, saves it, and responds with 303 Location: /contact/thanks. The browser then requests the thank-you page with GET. Refreshing that page refreshes the result view instead of submitting the form again. The address bar also ends on a safe, bookmarkable URL.

303 is not a method-preserving redirect. That is its purpose. Do not use it to move an API request when the destination still needs the original JSON body. The server should complete the action before returning 303, or it should provide a separate status resource that the client can fetch.

307 Temporary Redirect

A 307 is the temporary counterpart to 308. It explicitly preserves the original request method and body. A client following 307 Location: /v2/upload should send the same method and payload to /v2/upload rather than silently converting the request to GET.

This makes 307 a useful choice for temporary API routing, regional failover, a service maintenance window, or a temporary hostname change. It is also safer when an application accepts more than one method and the redirect layer should not guess what the application intended.

Preservation does not mean the request is automatically safe to repeat. A network failure can still cause retries, and a redirected non-idempotent request may be processed twice if the client or proxy retries it. Use idempotency keys for operations such as payments, account creation, or order submission. A correct status code helps preserve semantics; it does not replace application-level duplicate protection.

308 Permanent Redirect

A 308 communicates two facts at once: the destination is permanent, and the original method and body must be preserved. It is the best fit for a permanent API endpoint move when clients should continue sending the same request to the new URL.

For example, if POST /api/v1/import has moved permanently to /api/v2/import, a 308 lets a capable client repeat the POST with its payload. It can also be appropriate for permanent infrastructure changes where the application contract must not be altered by the redirect layer.

Use 308 carefully on public website URLs. A browser or crawler may remember the redirect, and an incorrect permanent redirect can be inconvenient to reverse. Before deploying it, confirm that the target accepts the original method, that authentication and request bodies are handled correctly, and that the destination is the true long-term home.

301 vs. 308: the permanent redirect decision

Choose 301 for a permanent move of ordinary web pages where the follow-up request is a GET, or where compatibility with older clients is more important than strict method preservation.
Choose 308 when a permanent move must keep POST, PUT, PATCH, DELETE, or another method and its body.

For a site migration, most page-to-page redirects are GET requests, so 301 remains familiar and widely supported. For an API migration, 308 makes the contract explicit. In both cases, point the old URL directly to the final relevant URL. Do not create a long series of permanent hops just because each historical URL has its own redirect rule.

302 vs. 303 vs. 307: the temporary redirect decision

Use 302 when the redirect is temporary and the original request is ordinary browser navigation, while the client behavior is known to be acceptable.
Use 303 when the action is complete and the client should fetch a different result page with GET, as in PRG.
Use 307 when the temporary destination must receive the original method and body unchanged.

These codes are not interchangeable labels for “send the visitor somewhere else.” The choice tells the next client whether it should repeat the operation, view another resource, or treat the original URL as a temporary detour.

Redirects for HTTPS, hostnames, and site migrations

For an HTTP-to-HTTPS rule or a canonical hostname rule, a 301 is usually appropriate when the traffic is page navigation. Keep the redirect direct: http://example.com/page should go straight to https://www.example.com/page if that is the chosen canonical URL. Avoid bouncing through several combinations of protocol, subdomain, and trailing slash.

During a migration, build a map from every important old URL to its closest matching new URL. A homepage redirect is not a good substitute for a missing product or article page. Retain query parameters when they carry useful campaign or application data, and check that the final page returns the expected status instead of another redirect.

For API hostnames, be more conservative. If a client sends a body to an old endpoint and the body must arrive at the new endpoint, test 307 or 308 with the exact SDKs and proxies your customers use. If the old endpoint should merely report that a job was accepted and the client should poll a result URL, 303 may be the better model.

How to check a redirect in practice

A status code alone is not enough. Check the complete chain and record:

the status returned at each hop;
the exact Location value, including scheme, host, path, and query string;
the final URL and final response status;
whether the client changed the request method;
whether the request body and relevant headers were retained;
the number of hops and the time spent at each one.

Redirect Chain Checker is useful for the first part of that investigation. Enter the starting URL, inspect every response in order, and look for unnecessary hops, a loop, a target that redirects again, or a final page that does not match the intended URL. For API work, reproduce the check with a command-line client or integration test that sends the real method and body. A browser-only check cannot prove that a JSON POST was preserved.

Common redirect mistakes

Using 301 for a temporary test. Permanent responses may be cached or retained by clients. Use 302, 303, or 307 while the destination is still being evaluated.

Using 302 or 303 for an API body. If the operation must continue as POST or PUT, these codes can change the request semantics. Use 307 for a temporary move or 308 for a permanent one.

Redirecting through several “temporary” rules. Each hop adds latency and creates another place for a loop or inconsistent cache behavior. Collapse the chain to one direct redirect where possible.

Ignoring the final response. A chain can look correct while ending in a 404, 500, a login page, or a different canonical URL. Always inspect the final status and content destination.

Forgetting the request method during testing. A HEAD or GET test does not tell you how a POST will behave. Test the method that the application actually uses.

FAQ

Is 301 always better for SEO? No. Use a permanent code only when the move is genuinely permanent and the destination is relevant. A temporary redirect should stay temporary, and neither type fixes an irrelevant target or a redirect chain.

Does 301 preserve POST data? You should not assume it will across all clients. Historical behavior commonly changes POST to GET. If the body must be preserved, choose 308 and test the clients that matter.

When should I use 303 instead of 302? Use 303 when you want the next request to be a GET, especially after a successful form submission. It clearly expresses the PRG pattern.

What is the difference between 307 and 308? Both preserve the original method and body. 307 is temporary; 308 is permanent.

How many redirects are too many? There is no single universal number, but one direct hop is preferable. Several hops add latency and increase the chance of loops, stale rules, and inconsistent client behavior.

FAQ

Is 301 always better for SEO?

No. Use a permanent redirect only when the move is genuinely permanent and the destination is relevant.

Does 301 preserve POST data?

Do not assume it will across all clients. Use 308 when the method and body must be preserved.

When should I use 303 instead of 302?

Use 303 when the next request should be GET, especially after a successful form submission.

What is the difference between 307 and 308?

Both preserve the original method and body. 307 is temporary; 308 is permanent.

HTTP Redirect Status Codes: 301, 302, 303, 307, and 308 Explained

What HTTP redirect status codes tell the client

HTTP redirect status codes quick reference

301 Moved Permanently

302 Found

303 See Other and the Post/Redirect/Get pattern

307 Temporary Redirect

308 Permanent Redirect

301 vs. 308: the permanent redirect decision

302 vs. 303 vs. 307: the temporary redirect decision

Redirects for HTTPS, hostnames, and site migrations

How to check a redirect in practice

Common redirect mistakes

FAQ

FAQ

Table of Contents

Information

Tags

More Posts

301 vs 302 Redirects: When to Use 301, 302, 307, and 308

How to Find the Final URL Behind a Short Link

What Is a Redirect Chain? A Clear Guide With Real Examples

Too Many Redirects: Causes, Diagnosis, and Fixes

Do Redirect Chains Hurt SEO? What Google Recommends

Redirect Audit Checklist: How to Find Chains, Loops, and Broken Targets