What is the difference between HTTP status 301 and HTTP status 302, and what does each one tell a browser, a cache, and a search engine to do?
answer
- 301 = permanent, cached hard, may be forever
- 302 = temporary, keep using the old URL, not cached by default
- Both carry Location; relative allowed
- 301 transfers search ranking, 302 does not
- 301 is a one-way door — 302 first, promote later
basics
~20 sBoth send the client to the URL in the Location header. 301 Moved Permanently says the resource has a new home — clients and caches may store it indefinitely and search engines transfer ranking. 302 Found says it is temporary — keep using the original URL, and do not cache by default.
solid answer
~50 sBoth are 3xx responses carrying a `Location` header the client should follow. - **301 Moved Permanently** — the resource has a new canonical URL. Clients are entitled to remember it: browsers cache 301s aggressively, often on disk and often *indefinitely* even without explicit `Cache-Control`. Search engines treat it as a canonical change and transfer ranking signals. Bookmarks and hard-coded links should be rewritten. - **302 Found** — the target lives elsewhere *right now*. The original URL stays canonical, so clients must keep requesting it, and the response is **not cacheable by default** (only if you add explicit freshness headers). The practical rule: **301 is effectively irreversible** at the client, so use it only when the move is final. Use 302 for anything conditional — A/B tests, geo or device routing, maintenance pages, "go to login then come back". One caveat: for historical reasons many clients rewrite a POST to a GET when following either code.
code
http · 9 linesHTTP/1.1 301 Moved Permanently
Location: https://www.example.com/docs/guide
Cache-Control: max-age=86400
Content-Length: 0
HTTP/1.1 302 Found
Location: /login?next=%2Fdashboard
Cache-Control: no-store
Content-Length: 0go deeper
Say permanent versus temporary, name the Location header, and give one example of each — a domain move for 301, a login bounce for 302.
Add the caching contract: 301 cacheable by default and persisted by browsers, 302 not cacheable unless explicit, plus the historical POST-to-GET rewriting on both.
Emphasise irreversibility at the client, sending explicit max-age on 301s, starting with 302 and promoting, and collapsing chains to save round trips.
Treat permanent redirects as a durable public commitment on par with an API contract: they outlive your infrastructure, are unrecallable from client caches and search indexes, and therefore need a mapping you are prepared to keep serving for years.
## The shared mechanics A 3xx redirect response tells the client the request should be re-issued somewhere else. The essential parts are the status code and a `Location` header holding the new URI (which may be relative — clients resolve it against the request URI). A short HTML body with a hyperlink is optional courtesy for clients that do not follow automatically. Browsers follow automatically and cap the chain (around 20 hops) before reporting a redirect loop. What separates 301 from 302 is not *where* you go but **what the client is allowed to remember**. ## 301 Moved Permanently 301 states that the target resource has been assigned a new permanent URI, and that future references should use it. Three consequences follow: **Caching.** A 301 is cacheable by default — it is one of the few status codes that a cache may store heuristically with no explicit freshness headers. Browsers go further and persist 301s to disk, frequently for the lifetime of the profile's cache. In practice, a returning user may never contact your server for that URL again. That is the single most important operational fact about 301. **Canonicalisation.** Search engines interpret 301 as "update your index" and pass ranking signals to the new URL. This is why site migrations are done with 301: it is the supported way to move accumulated authority. **Client rewriting.** Clients are told to rewrite stored references — bookmarks, link databases, crawler frontiers. Because you cannot reach into a browser cache to undo it, treat a 301 as a one-way door. Ship it only when the mapping is final. A prudent habit is to send an explicit `Cache-Control: max-age=…` on 301 responses so at least the duration is *yours* to choose rather than the browser's. ## 302 Found 302 means the target is temporarily at a different URI, and the client **must continue to use the original URI** for future requests. Its name was "Moved Temporarily" in HTTP/1.0 and was changed to "Found" in HTTP/1.1. It is **not cacheable unless the response says so** — with `Cache-Control: max-age` or `Expires`. Search engines do not transfer canonical status. This makes 302 the right choice whenever the redirect is a function of current conditions: an unauthenticated user bounced to the login page, a load-shedding maintenance page, an A/B split, geo or locale routing, a short-lived campaign URL, or a pre-signed download URL generated per request. ## The POST rewriting caveat Historically, browsers implemented 301 and 302 by converting a POST into a GET to the new location, dropping the body — behaviour that contradicted the original specification but became so universal that RFC 9110 now concedes a user agent **may** change the method for 301 and 302. The result is that with these two codes you cannot predict whether a POST is preserved. That ambiguity is exactly why 303, 307, and 308 exist, and it is the reason APIs should not rely on 301/302 for anything other than GET-shaped traffic. ## Choosing between them Ask two questions: *is the new URL the canonical one from now on?* and *am I willing for clients never to ask again?* Only if both answers are yes does 301 apply. Everything else is 302 (or 307 when method preservation matters). A reasonable rollout pattern for a genuine move is to serve 302 first, watch error rates and analytics on the new target, and promote to 301 once you are confident — because promoting is easy and demoting is not. ## Details worth knowing - The `Location` value may be relative; it is resolved against the effective request URI. - Many clients strip the `Authorization` header when a redirect crosses to a different origin, so credentialed calls can fail after a cross-domain redirect. - Redirect chains cost a full round trip each. Collapse `A → B → C` into `A → C` wherever you can. - A redirect that points at itself, or a pair that points at each other (often caused by an HTTPS-upgrade rule fighting a canonical-host rule), produces the browser's "too many redirects" error. - HSTS-driven upgrades from `http://` to `https://` are an *internal* browser redirect (reported as 307) and are not a server 301 — do not confuse the two when debugging.
- Why is it risky to use 301 for a redirect you might want to change later?Because a 301 is cacheable by default and browsers persist it to disk, often for the life of the cache and without ever revalidating. Once a client has stored it, your server is never consulted again for that URL, so changing the server configuration does not reach existing users. Sending an explicit Cache-Control max-age on 301 responses bounds the damage, and starting with 302 until the mapping is final avoids it entirely.
- You send a 302 in response to a POST. What method does the browser use for the follow-up request?Almost certainly GET, with the request body dropped. This behaviour contradicted the original specification but became universal, and RFC 9110 now permits it for both 301 and 302. If you need the POST and its body preserved, use 307; if you specifically want the deliberate switch to GET, use 303, which mandates it rather than leaving it to the client.
301 is filing a change-of-address form with the post office: everyone updates their records permanently. 302 is a sticky note on the door saying "back office today" — you still write to the same address tomorrow.
saying these in an interview costs you the question
- Saying 302 responses are cached like 301 responses
- Assuming a 301 can be undone by changing the server configuration
- Claiming both codes always preserve the request method
- Using 301 for login redirects or maintenance pages
- Thinking the difference is only about SEO and has no protocol meaning