HTTP 302 Found – Free, Online, Private

What HTTP 302 means

302 sends the client to Location for this request and does not promise the redirect will be there tomorrow. The historical method-rewrite bug applies: some clients turn POST into GET when following 302, same as 301. 303 exists to make 'see this other URL with GET' explicit, and 307 exists to keep the method. 302 remains common because old apps emit it for every redirect.

302 Found belongs to the 3xx redirection class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 302

When you see HTTP 302 Found, stop on that exact status line. 302 Found is a temporary redirect. Clients should keep using the original URL later. The trace that usually produces it: A login wall sent the browser to a sign-in URL. The 3xx redirection class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Use 302 for a temporary bounce when you do not care if the method changes, such as sending a browser to a login page. Use 303 after a POST when the next step is a GET. Use 307 when a temporary redirect must repeat the same method and body. Do not use 302 for a permanent move.

How to fix HTTP 302

To fix HTTP 302, change the condition that made the server choose Found. Follow Location for this request. Next time, start at the original URL again. Do not store 302 as the new canonical address. Retry the original URL later. Following Location is not a retry of a failed request. It is how this request finishes. If the log line is a different code, leave this page. The mix-up people make with 302 is this one: 301 is permanent. 307 keeps the method and is temporary. 303 says the follow-up must be GET.

• A POST-redirect-GET used 302 and a client replayed the POST.
• The Location pointed at the same URL and the client looped.
• A cache stored the 302 even though the status is temporary, because a header asked it to.

An access log that only stores 302 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 302 FoundHTTP/1.1 302 Found
Location: /login

Location is required for the redirect to work. The body can contain a hyperlink for clients that do not follow automatically. Browsers follow. A fetch() call follows redirects unless you set redirect to manual, in which case you read Location yourself.

What the client should do

Follow Location for this request. Next time, start at the original URL again. Do not store 302 as the new canonical address.

302 is not cached unless Cache-Control or Expires says so. If you need it cached, say so. If a proxy cached it anyway, that proxy is wrong.

Retry the original URL later. Following Location is not a retry of a failed request. It is how this request finishes.

Codes people confuse with HTTP 302

301 is permanent. 307 keeps the method and is temporary. 303 says the follow-up must be GET.