HTTP 300 Series Codes: The Redirect Guide

So think of this scenario where you click on a link and the page opens, seems easy?

But not always cause, sometimes the page you are trying to visit isn’t actually where you think it is. There are possibilities that the website moved it to a new URL, maybe it’s temporarily available somewhere else, or maybe there are multiple versions of the same resource. Instead of leaving you stuck somewhere, the server gives your further directions on where to move next. This process is called redirection, and it’s exactly what the HTTP 300 series is designed to handle.

To understand where the 300 series comes in the spotlight, it is helpful to know that HTTP status codes are divided into five groups. The 100 series means the server is still processing the request. The HTTP 200 code series means everything worked successfully. The 400 series points to a problem with the request, while the 500 series indicates a server-side issue.

In this guide, we’ll break down all of the HTTP 300 series codes, and explain when they will appear, and show why they matter.

That is a 300. The server has the content in multiple forms and is asking you to pick one. Sounds useful. In practice almost nobody uses this. Browsers do not pop up a menu asking you to choose. Servers usually just pick one version and send it. So 300 mostly just sits in the spec collecting dust.

 HTTP/1.1 300 Multiple Choices
Content-Type: application/json

{
  "choices": [
    "/article-en",
    "/article-es",
    "/article-fr"
  ]
}

The server is saying, “There are multiple versions available. Pick one.”

This one is the big one. Everyone uses this one. The server says: that page is gone from the old address. Not coming back. Here is the new address. Save it. Use it from now on. Your browser listens. Next time you go to the old address, your browser does not even ask the server. It just goes to the new address on its own. Because it is remembered. You see this all the time:

A site moves from http to https. Old articles move to new URLs. A whole website changes its domain name. Big reason this matters: Google pays attention to 301s. Whatever trust and ranking the old page had, it moves to the new page through a 301. So if your site changes URLs and you do not set up 301s properly, your search rankings basically restart from zero. That is painful.

Also worth knowing: “permanent” here just means the server intends it to be forever. You can technically change a 301 later. But browsers and Google cache these hard, so changes take a long time to spread.
.

HTTP/1.1 301 Moved Permanently

Location: https://example.com/new-page

Anyone visiting the old URL is permanently redirected to the new one

302 is like your friend texting you: “I am crashing at my cousin’s place this week only. Come here for now.” The server says: go to this other address right now. But the original address is still the real one. Come back to it next time. Browsers follow a 302 but do not save it. Next visit they check again with the server.

You run into 302 during logins. You try to open a page that needs login. The site sends you to the login page first, then sends you back. That whole back and forth uses 302 a lot. Also during A/B tests. Some users get sent to a test version of a page temporarily. Once the test ends, they go back to normal. Quick side note: 302 has a weird history. It was supposed to keep the request method the same when redirecting. So POST stays POST.

But browsers started switching POST to GET automatically when following a 302. That bug basically became the standard. And that mess is why 303 and 307 had to be invented.

HTTP/1.1 302 Found

Location: https://example.com/login

A common example is when a user needs to log in before accessing a page.

303 fixes part of the 302 mess. It says: go to this new address. And when you go there, use GET. No matter what method you used before. Why does this matter? Form submissions.User fills a form. Hits submit. That is a POST. Server handles the form. Now wants to show a thank you page. If the server just sends the thank you page back directly, the user hits refresh and the form submits again. Double order. Double account. Double whatever. Not good.

So server sends a 303 pointing to the thank you page. Browser makes a fresh GET request there. User hits refresh. Only the thank you page reloads. Form does not submit again. Developers call this Post Redirect Get. You will hear that term a lot.

HTTP/1.1 303See Other

Location: https://example.com/order-confirmation

After a form submission, the browser is told to load a separate confirmation page using a GET request.

304 is not really a redirect. It is the server saying: you already have this. Load your saved copy. Here is the full picture. When you visit a page, your browser saves a copy of it on your computer. That is called the cache.Next time you visit, your browser does not want to download everything again if nothing changed. So it asks the server: has anything here changed since I last visited?

If nothing changed, server replies with 304. No content sent. Browser loads from cache. Page appears fast. Server did almost no work. You benefit from this every day and never notice it. Those images and CSS files that load instantly on your second visit? 304 is doing that work silently.

HTTP/1.1 304 Not Modified

The server is saying, “Nothing has changed. Use the copy already stored in your browser cache.”

305 used to tell your browser to go through a specific proxy server to reach a resource. Do not use this. Ever. It got pulled from the official HTTP spec. A bad actor could use it to redirect your traffic through a proxy they control. Modern browsers completely ignore it or block it. Mentioned here only because you might see it in old documentation somewhere.

HTTP/1.1 305 Use Proxy

Location: http://proxy.example.com

This code is deprecated and ignored by modern browsers.

307 is what 302 should have been from the start. It says: go to this other address temporarily. And keep your request method exactly as it is. POST stays POST. GET stays GET. Nothing changes on its own.For APIs this matters a lot. Say an endpoint moves for a few days. You want clients to retry their exact request at the new address. 307 does that cleanly. 302 might accidentally switch the method. Think of it this way. 302 says: go over there, browsers will probably switch to GET, whatever. 307 says: go over there, use the exact same request, no sneaky changes.

HTTP/1.1 307 Temporary Redirect

Location: https://api.example.com/temp-endpoint

The browser must repeat the same request method at the new URL.

308 is about permanent redirects where the old address is dead. The new address is the home now. Update your links. And use the same method when you get there. Most developers just use 301 for permanent redirects because most pages use GET anyway. Method does not matter for those.308 becomes relevant when you permanently move an API endpoint and want clients to keep using POST or PUT without anything switching to GET behind the scenes.

HTTP/1.1 308 Permanent Redirect

Location: https://api.example.com/v2/orders

A permanent move while preserving the original request method.