HTTP Status Code Lookup

HTTP Status Codes — Complete Reference for 100 to 511

Every HTTP response from a server includes a three-digit status code that tells the client what happened. Codes are grouped into five categories: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), and 5xx (server error). This reference lists all 60+ registered codes with names, descriptions, common use cases, and links to the RFCs that define them. Each card also carries engineering badges — Cacheable (per the RFC 9111 heuristically-cacheable set), Retryable (safe to auto-retry with backoff), Keeps method, and Passes SEO equity — so on-call engineers writing retry, cache, or redirect layers can answer at a glance whether a code is safe to retry or cache. Filter by category or by Cacheable/Retryable, search by number or keyword with curl/Postman/observability workflows in mind, and review the Retry-After, X-RateLimit and RFC 7807 Problem Details guidance in the FAQ.

What are HTTP status codes and how are they organized?

HTTP status codes are three-digit numbers returned by a server in response to a client's request, defined primarily in RFC 9110 (HTTP Semantics, 2022) which superseded RFC 7231. They are grouped into five classes by the first digit: 1xx informational (request received, continuing), 2xx success (request was successfully received, understood, and accepted), 3xx redirection (further action needed to complete the request), 4xx client error (the request contains bad syntax or cannot be fulfilled), and 5xx server error (the server failed to fulfill a valid request). The full registry is maintained by IANA, and currently includes around 70 codes. Clients should treat unknown codes as the generic x00 of their class — so a brand-new 499 code should be treated like 400 by a client that doesn't recognize it.

What's the difference between 401 Unauthorized and 403 Forbidden?

These are routinely confused. 401 Unauthorized means "you have not authenticated — provide credentials." The response must include a WWW-Authenticate header telling the client what auth scheme to use (Basic, Bearer, Digest). The same request with valid credentials would succeed. 403 Forbidden means "I know who you are, and you are not allowed." Re-authenticating won't help; the credentials are recognized but lack permission for this resource. The name 401 is historically misleading — "unauthorized" should really be "unauthenticated." In practice, many APIs incorrectly return 401 for permission errors. RFC 9110 explicitly states that 403 should be used when the server understood the request but refuses to authorize it. A subtle related code is 407 Proxy Authentication Required, identical to 401 but for a proxy server in the chain.

When should I use 301 vs 302 vs 307 vs 308 redirects?

All four redirect, but they differ in two dimensions: permanent vs temporary, and whether the request method can change. 301 Moved Permanently and 308 Permanent Redirect both signal the resource has permanently moved — search engines transfer link equity. 302 Found and 307 Temporary Redirect signal a temporary move. The method-preservation difference is critical: 301 and 302 historically allow clients to change POST to GET on the redirect (per RFC compliance ambiguity), while 307 and 308 strictly require the same method and body. For SEO migrations, use 301. For POST endpoints that move, use 308 to preserve the body. For load balancing or A/B testing, use 302 or 307. Bing and Google have explicitly stated that 308 is treated equivalently to 301 for ranking purposes.

What does 429 Too Many Requests mean and how should I handle it?

429 (RFC 6585) means the client has sent too many requests in a given time and is being rate-limited. The response should include a Retry-After header — either a delta-seconds integer ("Retry-After: 60") or an HTTP-date — telling the client when to retry. Well-behaved clients should implement exponential backoff with jitter: don't retry exactly at the Retry-After time (every client would hit at once), instead retry between Retry-After and Retry-After + random jitter. Additional headers commonly seen but not in the RFC: X-RateLimit-Limit (the ceiling), X-RateLimit-Remaining (calls left in current window), X-RateLimit-Reset (Unix timestamp when window resets). The IETF draft draft-ietf-httpapi-ratelimit-headers proposes standardized RateLimit and RateLimit-Policy headers. Many APIs also return 503 with Retry-After for the same purpose; the key signal is Retry-After.

What is 418 I'm a teapot and is it real?

418 I'm a teapot is the most famous Easter egg in HTTP. It originates from RFC 2324 (Hyper Text Coffee Pot Control Protocol), an April Fool's joke published April 1, 1998. The intended meaning was that a teapot, when asked to brew coffee, must respond with this status. It is not part of the actual HTTP spec (RFC 9110 does not include it), and IANA does not register it. However, many web frameworks and libraries (Node.js, Go, Python, Rust) ship constants for HTTP 418 because developers genuinely use it for whimsical or hidden endpoints. Google's robots.txt for years returned 418 for certain user agents. Save 418 for jokes and honeypots — never use it for real error semantics, because clients are explicitly not required to handle it.

What's the difference between 500, 502, 503, and 504?

All four are server-side errors but indicate different failure modes. 500 Internal Server Error is the generic catch-all when an unexpected exception occurred in the application code — a NullPointerException, an unhandled promise rejection, a database query that exploded. 502 Bad Gateway means an upstream server returned an invalid response to a gateway/proxy (like NGINX talking to a misbehaving backend). 503 Service Unavailable means the server is temporarily overloaded or under maintenance and is intentionally rejecting requests; should include Retry-After. 504 Gateway Timeout means a gateway/proxy waited for an upstream server and timed out before getting a response. The distinction matters for ops: 500 means "fix the code," 502 means "check the backend service," 503 means "scale up," and 504 means "check network/upstream timeouts." Cloudflare adds non-standard 520-527 for more granular edge failures.

What does 422 Unprocessable Entity mean vs 400 Bad Request?

400 Bad Request means the syntax is wrong: malformed JSON, missing required headers, invalid query string format — the server cannot even parse what you sent. 422 Unprocessable Entity (originally from WebDAV RFC 4918, popularized by REST APIs) means the syntax is correct but the semantics are wrong: the JSON parses cleanly, but "email" is not a valid email address, or "age" is -5, or "endDate" is before "startDate". RFC 9110 reaffirms 422 for the broader HTTP audience. Most modern REST APIs (Stripe, GitHub, Rails) use 422 for validation errors, which lets clients distinguish "my code generated invalid JSON" from "my code generated valid JSON with invalid values." Pair 422 with a JSON body listing the field-level errors (RFC 7807 Problem Details is the standard format). 409 Conflict is a related code for state conflicts like duplicate resource creation.

What are the lesser-known status codes I should know about?

Beyond the common ones, several niche codes solve real problems. 100 Continue is used with Expect: 100-continue to avoid sending a large body if the server will reject it. 103 Early Hints (RFC 8297) lets servers send Link headers before the final response, enabling browser preloading. 226 IM Used is for delta encoding (rare). 308 Permanent Redirect is the method-preserving 301. 410 Gone signals a resource was deliberately removed and is unlikely to return — stronger than 404 and good for SEO de-indexing. 451 Unavailable For Legal Reasons (RFC 7725, named after Fahrenheit 451) is used for court-ordered content removal. 425 Too Early prevents replay attacks in TLS 1.3 0-RTT. 428 Precondition Required forces clients to use If-Match for conditional requests. 511 Network Authentication Required is what captive portals should return. Knowing these lets you communicate intent precisely.

Which HTTP status codes are cacheable by default?

RFC 9111 (HTTP Caching) defines a specific set of responses that are heuristically cacheable by default — that is, a shared cache may store them even without an explicit Cache-Control or Expires header. That set is: 200 OK, 203 Non-Authoritative Information, 204 No Content, 206 Partial Content, 300 Multiple Choices, 301 Moved Permanently, 308 Permanent Redirect, 404 Not Found, 405 Method Not Allowed, 410 Gone, 414 URI Too Long, and 451 Unavailable For Legal Reasons. The tool marks each of these with a Cacheable badge, and the Cacheable only filter narrows the grid to exactly this list. Three caveats: (1) this is the default — any response can still be made cacheable or non-cacheable with explicit Cache-Control directives; (2) responses with no-store, private, or a Vary: * header are never stored; and (3) error responses like 404 and 410 are cached only briefly using heuristic freshness (typically a fraction of the time since Last-Modified), which is why a fixed 404 can still appear cached for a short while. When in doubt, set Cache-Control explicitly rather than relying on the heuristic set.

Which 4xx and 5xx status codes are safe to auto-retry?

Retry safety depends on whether the request is idempotent and whether the failure is transient. The codes worth auto-retrying — always with exponential backoff and jitter, and honoring any Retry-After header — are: 408 Request Timeout, 425 Too Early, 429 Too Many Requests, 500 Internal Server Error (only for idempotent methods like GET/PUT/DELETE), 502 Bad Gateway, 503 Service Unavailable, and 504 Gateway Timeout. The tool flags these with a Retryable badge and the Retryable only filter isolates them. Never blindly retry 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, or 422 Unprocessable Content — the request itself is wrong and retrying the identical request will just fail again. For 500 on a non-idempotent POST, retrying risks creating duplicates; use an idempotency key (as Stripe and most payment APIs do) so the retry is safe. For 429 and 503, prefer the server-supplied Retry-After over your own backoff timer, and add jitter so a fleet of clients does not retry in lockstep (a thundering herd) the instant the window resets.

Key Features

• Every IANA-registered HTTP status code (60+) covering 100 through 511
• Detailed descriptions for the 25 most common codes (200, 301, 304, 401, 403, 404, 429, 500, 503, etc.)
• Search by code number or keyword across names and descriptions
• Filter by category: 1xx Informational, 2xx Success, 3xx Redirection, 4xx Client Error, 5xx Server Error
• Color-coded category indicators for instant visual recognition
• Direct links to the defining RFC for each code (RFC 9110, RFC 6585, etc.)
• Quick-jump buttons for the four most-searched codes (200, 301, 404, 500)
• Copy any status code to clipboard with one click for bug reports and documentation
• Use-case examples explaining when each code is appropriate
• Covers modern additions: 103 Early Hints, 308 Permanent Redirect, 425 Too Early, 451 Legal
• Includes RFC 2324's 418 I'm a teapot for completeness
• Pure JavaScript — no external libraries
• Works offline after first load
• Responsive grid layout for mobile and desktop
• 100% client-side — no requests are made by the lookup