HTTP Status Code Explorer | HTTP Response Codes Reference & Comparisons
Search and browse HTTP status codes with explanations, use cases, comparisons (401 vs 403, 500 vs 502 vs 503), and copyable examples.
No uploads. Everything runs locally in your browser.
Browse HTTP status codes by class, search by keyword, and open details to see when to use each code, common mistakes, and sample responses.
Interim response telling the client to keep sending the request body.
Large uploads where the server wants to confirm headers before body.
Rarely needed for typical APIs; not a final response.
HTTP/1.1 100 Continue
Server agrees to upgrade protocols (e.g., to WebSocket).
When honoring an Upgrade header (HTTP→WebSocket).
Don’t return if you aren’t actually switching.
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade
Request succeeded and returns a representation.
Standard successful GET/POST with a response body.
Don’t use when a new resource is created (prefer 201).
HTTP/1.1 200 OK Content-Type: application/json
Resource created as a result of the request.
Successful POST/PUT that creates a new resource; include Location header.
Use 200 if nothing new was created; include representation when helpful.
HTTP/1.1 201 Created Location: /items/123
Request succeeded, no body returned.
DELETE success or updates where no body is needed.
Don’t send a body with 204.
HTTP/1.1 204 No Content
Resource has a new permanent URL.
Permanent redirects; update clients/bookmarks.
Don’t use for temporary moves; prefer 308 for preserving method/bodies.
HTTP/1.1 301 Moved Permanently Location: https://example.com/new
Temporary redirect (often behaves like 303/307 depending on client).
Temporary moves when method change is acceptable (though 307/303 clearer).
Ambiguous semantics; prefer 303 (after POST) or 307 (method preserved).
HTTP/1.1 302 Found Location: /temp
Redirect to GET another resource (commonly after POST).
After POST to redirect user to a confirmation page via GET.
Don’t use when you need to preserve original method; use 307 instead.
HTTP/1.1 303 See Other Location: /receipt/123
Temporary redirect preserving method/body.
Short-term moves where POST/PUT bodies must be retried as-is.
Use 308 for permanent method-preserving redirects.
HTTP/1.1 307 Temporary Redirect Location: /maintenance
Permanent redirect preserving method/body.
Permanent move where POST/PUT bodies must stay intact.
Don’t use 301 if method must be preserved.
HTTP/1.1 308 Permanent Redirect Location: https://example.com/new
Malformed request syntax or invalid parameters.
Validation failures, malformed JSON, missing required fields.
Use 422 when semantics are correct but data is invalid; use 401/403 for auth issues.
HTTP/1.1 400 Bad Request Content-Type: application/json
Authentication required or failed.
Missing/invalid credentials; include WWW-Authenticate when applicable.
Don’t use for forbidden-with-auth cases (use 403).
HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer
Authenticated but not allowed to perform the action.
User is known but lacks permission for the resource.
Don’t use for missing auth (401).
HTTP/1.1 403 Forbidden
Resource doesn’t exist or is hidden intentionally.
Unknown routes, missing IDs, or to avoid revealing existence.
Use 410 when permanently gone; avoid for auth errors (401/403).
HTTP/1.1 404 Not Found
Request conflicts with current state (e.g., versioning, duplicates).
Optimistic locking failures, duplicate resource creation.
Use 422 for validation that passed syntax but failed business rules.
HTTP/1.1 409 Conflict
Resource permanently removed.
Content intentionally removed with no forwarding address.
Use 404 when unsure; use redirects when moved.
HTTP/1.1 410 Gone
Server won’t accept the request media type.
Wrong Content-Type (e.g., XML sent to JSON-only endpoint).
Use 406 for unacceptable response types instead.
HTTP/1.1 415 Unsupported Media Type
RFC 2324 Easter egg status.
Playful/feature-flag stubs; rarely in production.
Don’t use for real protocol behavior.
HTTP/1.1 418 I'm a teapot
Request well-formed but semantically invalid.
Domain validation failures after parsing succeeded.
Don’t use 400 when syntax is fine; don’t use 500 for business rule errors.
HTTP/1.1 422 Unprocessable Entity
Rate limit exceeded.
Throttle limits; include Retry-After.
Don’t hide rate limits as 500.
HTTP/1.1 429 Too Many Requests Retry-After: 60
Unexpected error on the server.
Unhandled exceptions or unknown server faults.
Don’t mask client errors; log and alert.
HTTP/1.1 500 Internal Server Error
Upstream server returned an invalid response.
Proxy/load balancer received bad response from upstream.
Use 500 for origin errors; use 503 for upstream down/overloaded.
HTTP/1.1 502 Bad Gateway
Service temporarily unavailable (overload/maintenance).
Planned maintenance windows or overload; include Retry-After.
Don’t use for permanent removal; that’s 410 with redirects.
HTTP/1.1 503 Service Unavailable Retry-After: 120
Upstream didn’t respond in time.
Edge/gateway timeouts waiting on upstream service.
Use client timeouts for local timeouts; log upstream latency.
HTTP/1.1 504 Gateway Timeout
What are HTTP status codes?
HTTP status codes are 3-digit responses that tell clients how a request was handled. They’re grouped into classes: informational (1xx), success (2xx), redirection (3xx), client error (4xx), and server error (5xx).
Status code classes
1xx = informational handshakes, 2xx = successful operations, 3xx = redirects, 4xx = client issues like validation or auth, 5xx = server or upstream faults. Use the most precise code to aid clients, debuggers, and search engines.
How to use this explorer
Search by code or keyword, filter by class, then open details to see when to use a code, what to avoid, and copyable example responses for your API docs or tests.
Common comparisons
200 returns content for successful actions, 201 signals creation (include Location), and 204 is success with no body—ideal for DELETE or idempotent updates without payloads.
301/308 are permanent; 302/307 are temporary. 301/302 may switch to GET, while 307/308 preserve method/body. Use 308 for permanent POST/PUT redirects.
400 = bad request/validation; 401 = auth required/failed; 403 = authenticated but not allowed. Don’t blur auth errors into 400.
404 means not found or intentionally hidden; 410 signals permanently gone. Use 410 when removal is deliberate and permanent.
409 is a state conflict (versioning, duplicates); 422 is semantically invalid after parsing succeeded. Use 422 for business rule failures.
500 is an origin error, 502 is a bad response from upstream, 503 is temporary unavailability/overload (often with Retry-After).
Why correct codes matter
Precise status codes improve API debuggability, client handling, caching, SEO crawl signals (301/308 vs 404/410), and user-facing error clarity. They also reduce support load by making failures self-explanatory.
How to use
- Search by code, title, or keyword.
- Filter by status class (1xx–5xx).
- Open a code to see usage, mistakes, and copyable snippets.
Features
- Searchable HTTP status code reference.
- Class filters and related code comparisons.
- Copy example responses for quick API testing.
- SEO-friendly content for developers and SREs.
FAQ
What are HTTP status codes?
They are 3-digit responses indicating the outcome of an HTTP request, grouped by class from 1xx to 5xx.
How do I choose the right status code?
Match the intent: creation → 201, no body → 204, validation errors → 400/422, auth failures → 401/403, temporary downtime → 503 with Retry-After.
Why does 401 differ from 403?
401 is for missing or invalid authentication; 403 is for authenticated users lacking permission.
When should I use 308 instead of 301?
Use 308 when you need a permanent redirect that preserves the original HTTP method and body.
Which codes impact SEO?
Proper 301/308 for permanent moves, 404/410 for removals, and avoiding 500/503 errors improves crawlability and ranking stability.