302 Found
The target resource resides temporarily under a different URI. The client should use the original URI for future requests.
Meaning & Description
Historically, this status code was defined as "Moved Temporarily". However, many early browsers implemented it incorrectly, changing `POST` requests to `GET` requests when following the redirect. To resolve this ambiguity, HTTP/1.1 introduced `303 See Other` (to explicitly change `POST` to `GET`) and `307 Temporary Redirect` (to strictly preserve the method). Today, `302` remains the most common temporary redirect, widely used for login flows and short-term promotions.
Common Causes
- Authentication middleware intercepting a request.
- Geographic or device-based temporary routing (e.g., redirecting mobile users to a mobile site).
- Short-term marketing campaigns.
How to fix a 302 error
- Check the `Location` header to see where the server is sending the client.
- If a `POST` request is unexpectedly turning into a `GET` request, consider using a `307 Temporary Redirect` instead.
- If search engines are indexing the temporary URL instead of the original one, ensure you haven't accidentally used a 301 instead of a 302.
- Verify that session cookies are being properly passed along if the 302 is part of an authentication flow.
Browser & SEO Behaviour
Browser Behavior
Browsers follow the `Location` header immediately. Unlike 301s, browsers typically do not cache 302s aggressively, ensuring the client checks the original URL again on the next request.
SEO Impact
Search engines follow the redirect but maintain the original URL in their index. They do not pass link equity to the temporary target.
CDN Behavior
CDNs usually do not cache 302 responses by default unless specifically configured to do so with Cache-Control headers.
Code Examples
HTTP/1.1 302 Found
Date: Mon, 12 Sep 2026 12:00:00 GMT
Location: /login?returnTo=/dashboard
Content-Length: 0app.get('/dashboard', (req, res) => {
if (!req.user) {
// Express defaults to 302 for res.redirect()
return res.redirect('/login');
}
res.send('Welcome to the dashboard');
});from fastapi import FastAPI, Depends
from fastapi.responses import RedirectResponse
app = FastAPI()
@app.get("/dashboard")
def dashboard(user: dict = Depends(get_current_user)):
if not user:
# FastAPI RedirectResponse defaults to 307, must specify 302
return RedirectResponse(url="/login", status_code=302)
return {"message": "Welcome"}func dashboardHandler(w http.ResponseWriter, r *http.Request) {
if !isAuthenticated(r) {
http.Redirect(w, r, "/login", http.StatusFound)
return
}
w.Write([]byte("Dashboard"))
}[HttpGet("dashboard")]
public IActionResult GetDashboard()
{
if (!User.Identity.IsAuthenticated)
{
// Returns a 302 Found
return Redirect("/login");
}
return View();
}curl -I http://example.com/protected-route
# Adding -L follows the 302 redirect automatically
curl -I -L http://example.com/protected-routeRaw HTTP Response Example
HTTP/1.1 302 Found
Location: https://app.example.com/login
Content-Length: 0
Connection: closeReal-world Examples
Frequently Asked Questions
What is the difference between 302 Found and 301 Moved Permanently?
A 301 tells search engines the move is permanent, passing link equity and updating the index. A 302 says the move is temporary, instructing clients and search engines to keep checking the original URL in the future.
Should I use 302 or 307 for a temporary redirect?
If you are redirecting a GET request (like a homepage), a 302 is perfectly fine and universally supported. If you are redirecting a POST request (like a form submission or API call) and need the target URL to receive the exact same POST payload, you must use a 307.
Why does my POST request turn into a GET request on a 302 redirect?
This is a historical quirk. Early browsers implemented 302s by converting POSTs to GETs. While this violates the original HTTP spec, it became so common that modern standards formalized this behavior. Use 307 to prevent it.
Can 302 redirects hurt my SEO?
Only if used incorrectly. If you use a 302 for a page that has permanently moved, search engines won't update their index to the new URL, and you won't pass SEO value to the new page.
How do I prevent Open Redirect attacks on a 302?
If your application redirects based on a query parameter (like ?returnUrl=), ensure you validate that the URL is relative (starts with a single slash) or belongs to a strict whitelist of allowed domains.
Did You Know?
The name of the 302 status code was originally "Moved Temporarily" in HTTP/1.0, but was changed to "Found" in HTTP/1.1 to reflect how it was actually being used.
Because 302 was implemented incorrectly by almost every early browser, the HTTP working group had to create two entirely new status codes (303 and 307) just to fix the mess.
Developer Tips
- Use 302 as the default for login routing. It ensures that when a user logs out and tries to access a protected page, they are directed to the login screen without caching the redirect.
- Always use absolute paths or fully qualified URLs in the Location header to avoid unexpected relative routing issues.
- Beware of frameworks that default to 302 for all redirects (like Express.js) when you might actually need a 301 for SEO purposes.
Interview Questions
These are questions you might face in a backend or API design interview that touch on HTTP 302.
Explain the historical controversy surrounding the 302 status code.
The original spec stated that 302 should not change the HTTP method. However, early browsers changed POST requests to GET requests when following a 302. To fix this, HTTP/1.1 introduced 303 (explicitly change to GET) and 307 (strictly preserve the method).
If you are building an OAuth flow, which HTTP status code is most appropriate for redirecting the user to the identity provider?
A 302 Found is most appropriate, as the redirection to the login server is temporary and should not be cached permanently by the browser.
What is an Open Redirect vulnerability, and how does it relate to the 302 status code?
An Open Redirect occurs when an application takes a user-supplied URL (e.g., in a query string) and issues a 302 redirect to it without validation. Attackers use this to craft legitimate-looking URLs that redirect users to phishing sites.
Common Interview Mistakes
- Confusing 302 (Found) with 301 (Moved Permanently) regarding SEO impact.
- Not knowing that 302 can alter a POST to a GET.
- Assuming 302 redirects are completely uncacheable (they can be cached if explicit headers are set).