HTTP Status Code Reference

The HTTP Status Code Reference is a complete, searchable index of every status code defined in the HTTP specifications — from 100 Continue all the way to 511 Network Authentication Required. Each entry shows the canonical name, the RFC that defines it, what the code actually means, when to send it, when not to send it, and the common pitfalls that bite real codebases. A live filter and category chips let you jump from class to class in one click.

Unlike a flat cheatsheet, this tool gives every code its own micro-page with three colour-coded panels (do / don’t / pitfalls) and ready-to-paste handlers for Express.js, Django, FastAPI, and Go net/http. The animated wire diagram shows the request travelling from client to server and the chosen status flowing back — useful for newcomers learning what a status code really represents on the wire.

Why a status-code reference matters

How to use the HTTP Status Code Reference

1. Quick lookup. Type a code (404) or a name fragment (teapot, gateway) into the search box at the top and submit. The matching entry opens with the full detail panel.
2. Browse by class. Click any of the 5 chips (1xx, 2xx, 3xx, 4xx, 5xx) to filter the grid to that class. Click All to reset.
3. Live filter. The filter box just above the grid narrows the cards as you type — useful when you remember half a name like too many or precondition.
4. Inspect a code. Click any card to open its detail panel. You will see the meaning, when to use, when not to use, common pitfalls, and a 4-framework snippet block.
5. Copy a snippet. Use the tab switcher and the small Copy button to grab a ready-to-paste handler.
6. Compare neighbors. The detail panel ends with sibling cards from the same class (1xx / 2xx / 3xx / 4xx / 5xx) for quick side-by-side comparison.

The five HTTP status classes at a glance

Frequently confused pairs

• 401 vs 403. 401 means unauthenticated — the request lacks valid credentials. 403 means authenticated but not allowed — the credentials are fine but the user lacks permission.
• 404 vs 410. 404 means unknown: maybe it exists somewhere, maybe a typo. 410 means deliberately removed: search engines should drop it from the index.
• 301 vs 302 vs 307 vs 308. 301 / 308 are permanent (308 strictly preserves method & body), 302 / 307 are temporary (307 strictly preserves method & body). Use 307 / 308 for POST / PUT / PATCH redirects.
• 400 vs 422. 400 means the request body is malformed (bad JSON, missing field). 422 means the body parsed cleanly but the values fail business rules (invalid email format, quantity out of range).
• 502 vs 503 vs 504. 502 means the upstream sent garbage. 503 means the server is overloaded or in maintenance. 504 means the upstream did not respond in time.
• 409 vs 412. 409 is a conflict with the current state of the resource. 412 specifically means a precondition header (If-Match, If-Unmodified-Since) evaluated to false.

Headers that pair with specific status codes

• 201 Created — should include Location pointing at the new resource.
• 301 / 302 / 307 / 308 — must include Location with the target URL.
• 304 Not Modified — must echo the headers that would have appeared on a 200 (ETag, Cache-Control, Vary).
• 401 Unauthorized — must include WWW-Authenticate listing accepted schemes (Basic, Bearer).
• 405 Method Not Allowed — must include Allow listing the methods that are allowed.
• 413 / 429 / 503 — often include Retry-After (seconds or HTTP-date) so clients back off correctly.
• 416 Range Not Satisfiable — must include Content-Range: bytes */<length>.

Status codes you can almost always ignore

A handful of codes are technically valid but extremely rare in modern APIs: 305 Use Proxy (deprecated), 306 (reserved, unused), 305, 506 Variant Also Negotiates, 510 Not Extended, and 508 Loop Detected. Most are kept in the registry for historical reasons. If your library or middleware emits one of them, treat it as a bug report against the library — not a hint to handle it specially.

FAQ

Does the tool include codes from RFCs other than 9110?

Yes. It covers RFC 9110 (HTTP semantics), RFC 6585 (additional 4xx / 5xx), RFC 4918 (WebDAV), RFC 5842 (WebDAV bindings), RFC 7725 (451), RFC 8297 (103 Early Hints), RFC 8470 (425 Too Early), and the famously playful RFC 2324 (418 Teapot).

Are these codes valid in HTTP/2 and HTTP/3?

Yes. Status code semantics are defined in RFC 9110, which is the version-independent HTTP semantics document. HTTP/2 (RFC 9113) and HTTP/3 (RFC 9114) only change framing and transport.

Can I link directly to a specific code?

Submit the form with a single code (for example 404) and the detail panel will load below the form. The URL shows your search and is safe to share — opening it loads the same result.

Why does my framework not let me return 418?

Older versions of some HTTP libraries refuse to emit codes that are not in their internal registry. The fix is to upgrade the library or, where possible, write the status line manually.

Should an API ever return 200 with an error body?

No. Monitoring, retries, and intermediaries all assume 2xx means success. If you must return error structure, return an appropriate 4xx or 5xx and put the structured detail inside the body. The Problem Details for HTTP APIs format (RFC 9457) is a good template.

Is there an authoritative registry of HTTP status codes?

Yes. IANA maintains the registry at iana.org/assignments/http-status-codes. This tool stays in sync with that registry plus the most commonly cited RFCs.