HTTP Status Codes covers 72 codes: every standard code defined by RFC 9110 (100–101, 200–206, 300–308, 400–418, 421, 422, 426, 500–505), the extension codes defined by RFC 6585 / 7725 / 8297 / 8470 and the WebDAV series (103, 207, 208, 226, 423–425, 428, 429, 431, 451, 506–511), and the non-standard codes that appear in no RFC yet show up every day when you debug production — nginx's 444 and 499, Cloudflare's 520–526.

Unlike tables that give only a “meaning”, every code here is written in four parts: what its semantics are; in what situation you will see it; what the front end / client should do with it (retry? go to login? which response header to read?); and when the back end should return it and which headers to send. High-frequency codes add a fifth part, “common misuse”, because most status-code problems in production come from using the wrong code rather than failing to recognize it — returning 200 for a business failure, 403 for a logged-out user, 503 for rate limiting.

The top of the page also has seven “easily confused” comparisons: 401 vs 403, 301/302/307/308, 400 vs 422, 404 vs 410, 502/503/504, 200/201/202/204, and 429 vs 503. These are the combinations most often asked about in interviews, code reviews and troubleshooting.

1. 01Type a status code— enter three digits (such as 502) in the search box and the exact matching card is pinned to the top.
2. 02Search by keyword— typing “rate limit”, “redirect”, “token expired” or “upload” matches across semantics, scenarios, handling advice and misuse.
3. 03Browse by class— the chips switch between 1xx–5xx and “non-standard”; tick “common only” to keep just the 16 high-frequency codes.
4. 04Copy and favorite— the top-right corner of a card copies short text such as “404 Not Found”; starring a card gathers it at the top of the page (stored locally).
5. 05Comparisons— with no filter active, seven comparison groups appear at the top; click a code in one of them to jump to its card.

Searching “429” gives this card (excerpt):

The matching back-end response looks like this:

429 Too Many Requests  Too many requests          RFC 6585
Meaning  Too many requests were sent within a given time (rate limiting).
When     API rate limits, too many login attempts, a crawler being throttled, an AI API over its per-minute quota.
Client   Read Retry-After (seconds or a date) and retry with exponential backoff; show a "try later" message; do not retry immediately.
Server   Send Retry-After and RateLimit-* headers; count per user / IP / API key.
Misuse   Rate limiting returns 403 or 503, so the client cannot tell a permission problem from "wait a while".

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30
RateLimit-Limit: 60
RateLimit-Remaining: 0
RateLimit-Reset: 30

{"error":"rate_limited","message":"at most 60 requests per minute, please retry in 30 seconds"}

The design intent behind the five classes

The first digit of a status code decides its class, and that is deliberate: even when a client does not know a specific code (a new 425, for instance), it can still handle it by class — every 4xx means “do not retry as-is, the problem is in the request”, every 5xx “retry later”, every 3xx “look at Location”. RFC 9110 explicitly requires clients to understand class semantics and allows them not to understand individual codes. That is also why a custom status code has to fall in the right hundred range.

Why 401 is called Unauthorized when it means “unauthenticated”

A historical naming mistake. Early HTTP did not distinguish authentication (who you are) from authorization (what you may do); 401 was named Unauthorized, but its companion WWW-Authenticate header and the semantics of “may succeed after supplying credentials again” both say authentication. RFC 9110 §15.5.2 now words it as "lacks valid authentication credentials". Remember one line: 401 = please log in, 403 = logging in will not help. The front end uses this to decide between redirecting to the login page and showing “no permission”; get it backwards and logged-in users are repeatedly bounced back to the login page.

The two axes of redirects: permanent / temporary, method-preserving or not

The four common redirect codes are really a 2×2 matrix. 301 and 308 are permanent (browsers and search engines remember the new address), 302 and 307 are temporary. Historically browsers turned a POST into a GET when handling 301/302; RFC 9110 acknowledges that reality and provides 307/308 as the strict versions that “must keep the method and the request body”. A 301 for an https redirect on a website is fine; when migrating an API endpoint, a POST has to use 307/308 or the request body is lost.

Caching and 304

304 is often mistaken for “saving a request”. In reality the browser still sent a conditional request with If-None-Match / If-Modified-Since, the server compared and answered 304 with no response body — what is saved is the transfer, not the round trip. Actually saving requests is the job of Cache-Control: max-age (inside the freshness window the browser does not ask the server at all); the two work together: use the response directly while max-age is valid, and renew it with a conditional request that gets a 304 once it expires. In DevTools, "200 (from disk cache)" is the former and "304" is the latter.

The three gateway brothers: 502 / 503 / 504

The most common 5xx family in production, and telling them apart narrows the search immediately. A reverse proxy (Nginx, a gateway, a CDN) cannot connect to the upstream, or the upstream returned something invalid — 502, so go and check whether the application process is dead. The upstream explicitly says it is busy or under maintenance — 503, usually returned on purpose, so look at health checks and circuit breakers. The upstream does not answer — 504, so look at slow queries and timeout settings. Cloudflare splits these three cases into 520–526, where 521 ≈ 502 (connection refused), 522/524 ≈ 504 (connection / read timeout) and 525/526 are TLS-layer problems.

Status codes and business codes must agree

The most common anti-pattern is returning 200 for every request and putting the error in a code field of the response body. It lets CDNs cache error pages, disables 5xx alerts in monitoring, makes the browser's fetch().ok meaningless and leaves retry strategies with nothing to work from. The right split is for the HTTP status code to express what happened at the request level (RFC 9110 semantics) and the body's business code to express the domain detail — the two divide the work instead of replacing each other: out of stock is 422 + {"code":"OUT_OF_STOCK"}, not 200 + {"code":500}.

Selection criteria

— all status codes in RFC 9110, extension codes in the IANA registry, and private codes explicitly listed in nginx and Cloudflare documentation. The semantics and handling advice follow the corresponding RFC text; the handling advice is a summary of engineering practice, not a specification requirement.

What is not included

— private codes from single vendors such as IIS, AWS ELB and Shopify (440, 460, 463, 430 and others), which only appear in a specific product's logs so consult that vendor's documentation; and historical draft codes that have been removed from the registry.

Naming

— 413 and 422 use the RFC 9110 names (Content Too Large, Unprocessable Content); the old names (Payload Too Large, Unprocessable Entity) are noted in the spec field.

What it does not do

— it does not send requests to test your API (use the URL tool to analyze an address, or curl, when you need that); it is not a reference for HTTP header fields.

Status-code data is downloaded statically with the page; searching, filtering, copying and favorites all happen locally in your browser and send no requests. Favorites are stored in this browser's localStorage. The external links point to the RFC Editor, IANA and Cloudflare documentation and are handled by those sites once clicked.

• RFC 9110 §15 Status Codes（访问日期：2026-09-09）— the normative definition of every standard status code, including what each one requires of caches and methods.
• RFC 6585 Additional HTTP Status Codes（访问日期：2026-09-09）— the definitions of 428, 429, 431 and 511, and the use of Retry-After.
• IANA HTTP Status Code Registry（访问日期：2026-09-09）— the authoritative registry for checking whether a code really exists.
• Cloudflare 5XX error troubleshooting（访问日期：2026-09-09）— the cause list for each of 520–526.
• MDN: HTTP response status codes（访问日期：2026-09-09）— a Chinese-language reference with browser-compatibility notes.