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. Filter by category, search by number or keyword, or copy any code to your clipboard for documentation, bug reports, or commit messages.

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

The two codes look similar but mean different things:

- **401 Unauthorized** — the client has not authenticated, or the authentication failed. The fix is to log in or send a valid token. The response should include a WWW-Authenticate header telling the client how. Confusingly, despite the name, 401 means 'unauthenticated.'

- **403 Forbidden** — the client is authenticated but doesn't have permission for this specific resource. No amount of retrying with the same credentials will fix it; the user simply lacks access.

A common pattern in security-sensitive applications is to return 404 Not Found instead of 403 to avoid revealing that a restricted resource even exists. For example, GitHub returns 404 for private repos you don't have access to, not 403.

Should I use 301 or 308 for a permanent redirect?

It depends on the HTTP method. The two codes mean the same thing semantically (both are permanent redirects), but they behave differently when the original request was POST/PUT/DELETE:

- **301 Moved Permanently** — RFC 9110 explicitly allows clients to change the request method to GET when following a 301. Historically, most browsers always did this, even for POST. Use 301 only for GET redirects.

- **308 Permanent Redirect** — explicitly preserves the original method. POST stays POST, DELETE stays DELETE. Use 308 when the redirect must work for API endpoints.

For websites that mostly redirect GET requests (e.g., HTTP → HTTPS, www → non-www), 301 is fine and slightly better-supported in old clients. For APIs and forms, prefer 308.

The same distinction exists for temporary redirects: 302 (loose) vs. 307 (preserves method).

When is 422 Unprocessable Content appropriate?

422 is the right code when the request syntax is valid (well-formed JSON, correct content-type) but the *semantic* content is wrong. The classic example is a sign-up form where:

- The JSON parses correctly → not 400
- The email field is present → not a missing-field error
- But the email address is malformed (e.g., 'not-an-email') → 422 Unprocessable Content

Vs. 400 Bad Request which should be reserved for:

- Malformed JSON (parse error)
- Missing required fields
- Wrong content-type header

In practice, many APIs use 400 for everything client-side, and that's acceptable too. The distinction matters when you want to give clients a programmatic way to tell 'fix your data' from 'fix your request format.' GitHub, Stripe, and most modern REST APIs use 422 for validation errors.

What's the right code for rate limiting?

**429 Too Many Requests** is the canonical answer (RFC 6585). The response should include:

- A **Retry-After** header — either seconds (`Retry-After: 60`) or an HTTP date — telling the client when to retry.
- An optional body explaining the limit. JSON like `{"error": "rate_limit_exceeded", "retry_after": 60}` is common.
- An optional **X-RateLimit-Limit**, **X-RateLimit-Remaining**, **X-RateLimit-Reset** header trio for clients to track quotas. (These aren't standardized but are widely adopted by GitHub, Stripe, Twitter, etc.)

For DDoS-style protection where you want to drop the request silently, returning 503 Service Unavailable with a long Retry-After is sometimes used as an alternative.

Avoid using 503 for normal rate-limiting because it tells the client the *server* is failing, not the client. 429 is the right signal that 'you are sending too much, slow down.'

Is 418 'I'm a teapot' real?

Yes, sort of. RFC 2324 defines the HyperText Coffee Pot Control Protocol (HTCPCP), an April Fools' RFC from 1998 that specified protocols for brewing coffee over HTTP. Any attempt to brew coffee with a teapot returns 418 I'm a teapot.

The code is officially registered with IANA but is reserved as a joke. In 2017 there was a half-serious push to remove it from server libraries (Node.js briefly removed support); the community pushed back, and most stacks kept it. It's now safely enshrined as part of HTTP folklore.

Real-world use cases for 418 are limited:

- **April Fools' Day pranks** — some sites return 418 from a /teapot endpoint.
- **Easter eggs** in API documentation.
- **Detecting automated scrapers** — some sites return 418 for suspicious traffic patterns since real clients won't expect it.

Don't use 418 in production for actual errors — clients won't know what to do with it. Stick to standard 4xx/5xx codes.

What does 503 mean and how is it different from 500?

**500 Internal Server Error** is a generic catch-all: the server hit an unexpected condition (a bug, an unhandled exception) and couldn't complete the request. The implication is that retrying immediately probably won't help — something is wrong on the server side.

**503 Service Unavailable** is more specific: the service is temporarily down, usually because of overload, planned maintenance, or autoscaling lag. The implication is that retrying later (often with the **Retry-After** header indicating when) will succeed.

A few subtleties:

- A load balancer returning 503 means the upstream is unreachable. Look at the LB error logs.
- An application returning 503 means it's intentionally rejecting requests (maintenance mode, circuit breaker tripped).
- 503 should never be returned by an app crash — that's 500 territory.
- Cloudflare and other CDNs have their own 5xx codes (520, 521, 522, 523, 524, 525, 526, 527) for specific upstream errors. These aren't IANA-registered but appear in browser dev tools.

Why is the 1xx range rarely seen in tools?

1xx codes are intermediate — they're sent *before* the final response. Most tools (browsers, curl, Postman) don't surface them because by the time the final 2xx/3xx/4xx/5xx response arrives, the 1xx context is gone.

The three you'll occasionally see:

- **100 Continue** — sent when a client uses `Expect: 100-continue` to ask whether the server will accept a large upload before sending the body. Helps avoid wasting bandwidth on rejected POSTs.
- **101 Switching Protocols** — sent during a protocol upgrade, most commonly the WebSocket handshake. The browser dev tools show this in the Network tab for any active WebSocket connection.
- **103 Early Hints** — newer (2017, RFC 8297). Lets the server send `Link: preload` hints before the final response, so the browser can start downloading CSS, JS, and fonts in parallel. Used by Cloudflare and Fastly.

102 Processing exists (RFC 2518 for WebDAV) but is barely used outside niche WebDAV servers.

Where do these codes come from?

HTTP status codes are defined across multiple RFCs:

- **RFC 9110** (June 2024) — the current HTTP semantics specification, defining the base 1xx, 2xx, 3xx, 4xx, 5xx codes. Replaced RFC 7231 in 2024.
- **RFC 4918** — WebDAV (207 Multi-Status, 422 Unprocessable Content [now in 9110], 423 Locked, 424 Failed Dependency, 507 Insufficient Storage).
- **RFC 6585** — Additional HTTP status codes (428, 429, 431, 511).
- **RFC 7538** — 308 Permanent Redirect.
- **RFC 7725** — 451 Unavailable For Legal Reasons.
- **RFC 8297** — 103 Early Hints.
- **RFC 8470** — 425 Too Early (TLS 1.3).
- **RFC 2324** — 418 I'm a teapot (April Fools' joke).
- **IANA HTTP Status Code Registry** — the authoritative list of all registered codes.

Each card in this reference links to the RFC that defines that status code, so you can always go to the authoritative source for edge cases.

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