The Core Difference
Both responses say that the requested resource is temporarily available at the URL in the Location header. The difference is what the client does with the original HTTP method and body.
When a client automatically follows a 307 Temporary Redirect, it must repeat the request using the same method and body. A POST remains a POST, a PUT remains a PUT, and their payloads are sent to the new location.
With 302 Found, user agents historically changed a POST into a GET when following the redirect. Modern HTTP semantics permit this behavior for compatibility, so an application cannot rely on method preservation after a 302.
| Behavior | 302 Found | 307 Temporary Redirect |
|---|---|---|
| Redirect is temporary | Yes | Yes |
| GET and HEAD remain unchanged | Yes | Yes |
| Non-GET method guaranteed to be preserved | No | Yes |
| Request body guaranteed to be preserved | No | Yes |
| Useful after a successful form POST | Sometimes, but prefer 303 | No, unless repeating POST is intended |
| Useful for temporary API relocation | Risky | Yes |
Why Historical Behavior Matters
Consider an API receiving this request:
POST /v1/orders HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"sku":"A-42","quantity":1}If /v1/orders returns a 302, a client may follow the redirect as:
GET /v2/orders HTTP/1.1
Host: api.example.comThe method and payload have been lost. If the client automatically follows a 307 response, it must repeat the original POST and body at /v2/orders.
When to Use 302
Use 302 for a temporary navigation where requests are GET or HEAD, or where compatibility behavior is intentional and tested. Examples include temporarily routing users to a maintenance page or selecting a temporary presentation URL.
Do not use 302 when correctness depends on preserving a non-GET method. Even if one tested client preserves the method, another conforming client may use the historical POST-to-GET behavior.
When to Use 307
Use 307 when an endpoint is temporarily hosted elsewhere and the receiving endpoint is designed to accept the same method and body. This is especially relevant for APIs, upload endpoints, and temporary infrastructure routing.
HTTP/1.1 307 Temporary Redirect
Location: https://uploads.example.net/v1/files
Cache-Control: no-storeOnly redirect a credential-bearing request to an origin you trust. Redirecting an Authorization header or request body across origins can expose sensitive data, and clients may deliberately strip credentials during the redirect.
When 303 Is the Better Choice
After successfully processing a form submission, applications often want the browser to load a result page with GET. Use 303 See Other to express that behavior explicitly:
HTTP/1.1 303 See Other
Location: /orders/123/confirmationThis avoids accidental resubmission when the user refreshes the result page. A 307 would repeat the POST and could create a duplicate operation if the endpoint is not idempotent.
Caching and Search Indexing
Neither status is permanently cacheable merely because of its status code. Explicit cache headers can make a temporary redirect reusable for a limited period, but keep that lifetime short enough for the original URL to resume service when expected.
Because both redirects are temporary, the original URL should normally remain the canonical address. Use 301 or 308 when the move is permanent.
Decision Rule
- Temporary GET navigation: 302 or 307; 302 is widely conventional.
- Temporary relocation that must preserve method and body: 307.
- POST completed; load a result page with GET: 303.
- Permanent move that may convert POST to GET: 301.
- Permanent move that must preserve method and body: 308.
Use the Redirect and Canonical Auditor to inspect deployed redirect behavior.