HTTP Status Code Lookup

The cron job died at 2:14 a.m. and left exactly one clue: a three-digit number. No stack trace, no exception text — just `HTTP 429` in the log where a 200 should have been. The number means nothing to your gut, everything to the protocol, and the difference between 'the API is down' and 'you are being throttled' is the difference between filing a false incident and adding one sleep statement.

That is the whole reason status codes exist: HTTP is a protocol designed to be debugged by three digits. The first digit gives the class — did the client mess up, did the server mess up, or is something redirecting? The last two narrow the cause. Every response carries one, every proxy and gateway and rate limiter in the world speaks them fluently, and yet almost nobody can recite past the top ten. We built the HTTP Status Code Lookup above for the moment the three digits appear: type the number, or a phrase like 'too many requests,' and get the meaning, the likely causes, and the fix hints in one screen.

This article is the field guide version: the five classes and what they're actually telling you, a real 502 debugged end to end, the codes people misuse deliberately, and the redirect family that everyone conflates. The lookup tool handles the reference work; the words below handle the judgment.

1. 1

   Type what you have

   A number ('429'), a phrase ('too many'), or a symptom ('rate limit'). The search matches code, name, and description as you type — no form submission, no page reloads.

2. 2

   Or browse by class

   Five class filters — 1xx through 5xx — for when you know the family but not the member. Tap a class, scan the list, tap the row.

3. 3

   Read the entry

   Each code's card gives the formal meaning, when it appears in practice, the common causes ranked by real-world frequency, and the response headers that matter alongside it.

4. 4

   Follow the fix hints

   Concrete remediation per cause — Retry-After handling for 429, cache purge for 301 mistakes, upstream health for 502 — written for the person holding the pager, not the person writing the RFC.

5. 5

   Check the neighbors

   Confusable codes are cross-linked: 401 against 403, 502 against 504, the four redirects against each other. The distinctions are where the debugging skill lives.

The class digit is the protocol's grammar. Learn the five sentences it can say, and any three-digit number becomes at least half-understood before you look it up:

Within the classes, a handful of codes carry disproportionate weight. 204 No Content — success with an intentionally empty body, the correct response to a DELETE. 304 Not Modified — the quiet hero of the web: conditional request headers matched, reuse your cache, zero body transmitted; a large fraction of all successful web traffic is 304s nobody ever sees. 307 and 308 — the redirects that preserve the request method, which matters the moment a POST is involved. 422 Unprocessable Content — the validation error that 400 sweeps under the rug: the request was well-formed, the semantics were wrong. 429 — the rate limiter speaking. And on the 5xx side, the load-balancer trio: 502 broken upstream, 503 unavailable (often with Retry-After), 504 timed-out upstream.

One structural fact that surprises people: the human-readable phrase after the number — 'Not Found,' 'Bad Gateway' — is decoration, not protocol. Clients branch on the number; phrases are for logs and humans; and in HTTP/2 and HTTP/3, the wire format doesn't transmit the phrase at all, only the three digits in binary framing. Which is why the lookup here keys on numbers, and why your code should too.

Most codes are engineering; a few are folklore. Three entries in the registry carry stories worth knowing, because the stories also explain the mechanics.

103 Early Hints exists because of the wasted milliseconds at the start of every dynamic page. While the origin spends three or four hundred milliseconds computing the real response, the browser sits idle — even though it could already be downloading the CSS and JavaScript the page will need regardless. RFC 8297 lets the server send a preliminary 103 carrying Link headers first, the browser warms those fetches, and the final 200 arrives into an already-busy connection. Browser support landed in 2022, and CDNs can emit the hints on the origin's behalf using a cached hint table, which is where most real deployments get the effect without touching application code.

418 I'm a teapot comes from RFC 2324, the 1998 April Fools' specification for the Hyper Text Coffee Pot Control Protocol, which defined a server's proper response to an attempt to brew coffee with a teapot. The story nearly ended in 2017: the HTTP working group, running short on 4xx numbers, floated reclaiming parts of the range, and 418 sat in the blast radius. An internet campaign — complete with its own website and an unreasonable quantity of teapot memes — persuaded everyone to leave it reserved. It survives in the IANA registry as the only status code protected largely by affection.

451 Unavailable For Legal Reasons, RFC 7725 from 2015, is the deliberate nod to Ray Bradbury's Fahrenheit 451 — censorship as a self-reported status. The design argument was measurement: a legal block disguised as a 403 or a 404 is invisible to anyone studying takedowns, while a 451 can be counted, mapped, and cited. GitHub uses it for regionally blocked repositories, Cloudflare exposes it as a per-jurisdiction toggle so site owners can comply with local orders without pretending the page never existed, and the response is supposed to explain which legal obstacle applies. Of all the codes, it is the one that turned a silent refusal into a citable fact.

Here is the shape of a real 502 investigation — the kind that this lookup's fix hints compress into a checklist. The setup: a public site behind a CDN, an origin behind a load balancer, the pager firing with '502 Bad Gateway' from the CDN's edge.

1. Class check first. 5xx means the client's request was plausibly fine — do not waste the first ten minutes on 'what did the request look like.' Something on your side is broken or unreachable.
2. Locate the hop that generated it. The 502 was emitted by the CDN, which means the CDN's upstream — your load balancer — returned something invalid. A 502 always comes from the box in front, describing the box behind.
3. Ask which failure flavor it is. 502 says the upstream answered with garbage or closed the connection mid-response: crashed worker, malformed response, TLS handshake failure between the hops. (Had it been 504, the upstream would have simply been silent past the timeout — a different suspect list.)
4. Check the origin directly. Bypass the CDN and hit the load balancer or an origin host by IP with curl. Whatever comes back — empty reply, connection reset, an application error page — is the actual failure the CDN was reporting secondhand.
5. Look at the app's own logs at the matching timestamp. In the classic case: an OOM-killed worker pool, or a deploy that crashed on boot while the load balancer kept routing to it. The 502 was never the bug; it was the messenger.
6. Fix forward, then close the loop with the CDN. Restore origin health, confirm the edge returns 200s, and then — the step everyone skips — check how long the CDN cached the error. Some CDNs cache 5xx responses briefly, which turns a 90-second outage into a 20-minute one that 'won't go away.'

The general skill this story demonstrates: a status code tells you where in the chain the truth ended. 502 means truth ended at the hop in front of the failure. 429 means truth is at the server's quota system. 403 means truth is at an authorization check that already ran. Read the number as a location, not a verdict, and the debugging becomes topology.

Some misuse is ignorance, and some is policy. The deliberate kind is worth knowing because you will meet it in the wild and it changes what you can conclude:

• 404 where 403 belongs. Many APIs return 404 for resources you aren't allowed to know exist — confirming existence with a 403 would leak information to an attacker enumerating IDs. Defensible security design, and deeply confusing the first time you debug it: your request is correct, your token is valid, and the answer is still 'nothing to see here.'
• 500 for everything. Applications that funnel all failures through a generic 500 — validation problems, missing records, bad tokens — turn the class system off. Nothing distinguishes client-fixable from server-broken, so every client error becomes an ops page. The lookup can't fix that; only the API can.
• 301 for temporary moves. Browsers cache 301 aggressively and permanently. Using it for a weekend maintenance redirect means some visitors ride that redirect for months after you remove it. Temporary means 302, 303, or 307 — never 301.
• Redirect chains that ping-pong. Each hop is a round trip and a ranking consideration; audit them occasionally. A chain that ends in a loop — 301 to a URL that 301s back — is a soft outage for every affected page, and the lookup's redirect entries link straight to a chain-checking tool for exactly this reason.
• Non-standard codes in the wild. Some CDNs add their own 5xx-family codes for specific edge failures, and at least one large social platform famously returns 999. Nothing in the protocol forbids it; everything in interop practice argues against it. Unknown codes degrade to their class — an unregistered 4xx is just 'some client error' to every generic client in the world.

The audience for a status reference is everyone who touches HTTP, which is nearly everyone who touches the web — but the usage patterns cluster.

Backend and frontend developers look up the codes they meet in integration work: the API returning 422 where the docs promised 200, the OPTIONS preflight dying on a 405, the difference between a 401 that needs a token refresh and a 403 that needs a support ticket. SREs and on-call engineers live in the 5xx family and the topology reasoning of the 502 story above — the class digit is their triage instrument. API designers make forward-looking decisions: which code for idempotent-replay conflicts (409), which for async job creation (201 with a Location header), which for 'semantic validation failed' (422 rather than a lazy 400). SEO specialists practically live in the 3xx family — 301 versus 302 carries ranking weight, 451 explains geo-blocked pages in audits, and a site accidentally serving 429 or 511 to crawlers is a silent indexability disaster, which is why the Indexability Tester pairs with this lookup so naturally. And students meet the code list in networking courses and discover, usually with mild delight, that 418 is a real thing with a real RFC.

The design bet here is narrow and honest: most status-code lookups happen under mild time pressure with a number already in hand, and the winning interaction is type-three-digits-read-answer. MDN remains the reference to cite in documentation; the RFC remains the arbiter of what a code means when stakes are high. This tool is the one you can work inside — searching by symptom, hopping between confusable codes, and reading fix steps written for the on-call shift rather than the standards process.

Every code entry in the lookup ships with the page itself — the entire reference is a local data file, and the search runs over it in memory. No request goes anywhere when you look up a code, which is why the search feels instant and why the page keeps working with the network unplugged.

There is also nothing worth sending: a status code query is the least sensitive input imaginable. But the offline property earns its keep in real situations — on a locked-down production jump host with no outbound internet, in an incident bridge where the last thing anyone needs is a reference site failing to load, or on a plane where the API you're documenting against is a local mock. Reference material that requires connectivity is reference material that abandons you at the exact moments references matter most.

A status code is one clue in a request's story, and the neighboring tools on this site cover the rest of the chapter. The curl Command Converter turns the request you were making into fetch or Python so you can reproduce the failure in code — indispensable when the 429 only happens from your job runner. The Cron Expression Builder handles the other half of that 2:14 a.m. story: the schedule that put your request in the rate limiter's blast radius in the first place. And the Indexability Tester checks what the crawlers actually receive — because a 429 or 302 loop aimed at bots is invisible in your browser and expensive in search.

Reproduce the request, question the schedule, audit what crawlers see. Status codes connect all three, which is why they deserve a fast lookup and a little understanding.

Status semantics are normatively defined in the HTTP specifications, and the registry is the official list of what exists. These are the references this lookup was built against: