HTTP Status Code Lookup

HTTP status codes: a searchable reference with causes, fixes and a bulk URL checker

A status code is the first line of every HTTP response, and it is the server telling you what happened before it tells you anything else. This page is a reference for 62 of them — every code in current use across all five classes — and each entry carries a plain description, the causes that actually produce it, concrete steps to fix it, its RFC reference, and related codes you probably also want to read.

The reference tab has a search box that matches on the number, the reason phrase and the description text, so typing 429, rate or too many all land in the same place. There is a jump-to-code box for going straight to a number, filters for the five classes, and a security filter that narrows the list to codes with authentication, authorisation or exposure implications. Results show as a grid or a flat list, paginated twelve at a time, and clicking any code opens a detail panel. Several of the heavily used codes — 301, 302, 401, 403, 404, 429, 500 — also carry copy-ready configuration snippets for Nginx, Apache, Express and Next.js. Ctrl/Cmd+K focuses search; Esc closes the detail panel.

The five classes

The dividing line between 4xx and 5xx is responsibility, and it is worth being strict about it. A 4xx says “you asked wrongly”; a 5xx says “I broke”. An API that returns 500 for a validation failure is lying to its callers and will drown its own error dashboards. An API that returns 400 for a database outage hides a real incident.

301 vs 302 vs 307 vs 308

Two questions separate these four: is the move permanent, and is the HTTP method preserved?

The method-rewriting on 301 and 302 is not a browser bug; it is behaviour that predates the specification and was then documented as permitted. 307 and 308 exist precisely to remove the ambiguity. Practical consequences:

• Moving a page for good? 301. Search engines consolidate signals onto the target, and browsers cache it — sometimes very stubbornly, which is why a mistaken 301 is painful to unwind. Test with a 302 first if you are unsure.
• Redirecting an API endpoint that takes POST? 308, not 301. A 301 can turn your POST into a GET and the body vanishes silently.
• Maintenance page, A/B test, geographic bounce? 302 or 307 — anything you intend to reverse.
• Post/Redirect/Get after a form submission? 303. It is the code that says “the POST worked; now go GET this other thing”, which is what stops a browser refresh from resubmitting.

Also in the class: 300 Multiple Choices, rarely used; 304 Not Modified, the caching response to a conditional request carrying If-None-Match or If-Modified-Since, which returns headers and no body and is the single cheapest response a server can send; and 305 Use Proxy, deprecated and ignored by modern clients. Note that 306 is reserved and no longer used, which is why the list jumps from 305 to 307. When you need to trace where a chain of these actually terminates, the site’s redirect-chain-checker follows the hops one at a time.

401 vs 403

401 Unauthorized means unauthenticated — the name is a long-standing misnomer. The server does not know who you are, or the credentials you sent were rejected. A conforming 401 must include a WWW-Authenticate header describing how to authenticate. The fix is on the credential path: send a token, refresh an expired one, correct the scheme.

403 Forbidden means the server understood the request and is refusing it, and re-authenticating will not change the outcome. The identity may be perfectly valid and simply lack the right. The fix is on the permission path: role assignments, ACLs, file ownership, bucket policy.

The test that settles it: would sending better credentials fix this? If yes, 401. If no, 403. Two wrinkles worth knowing. Some servers deliberately return 404 instead of 403 for resources you may not even know exist, because a 403 confirms existence and leaks structure — a legitimate trade of correctness for privacy. And a great many reported “403 errors” in browser consoles are actually CORS failures: the request was blocked or rejected at the origin policy layer, not because of any permission on the resource. Check the response headers before you go looking at file permissions. Related codes: 407 Proxy Authentication Required, which is 401 for a proxy rather than the origin, and 511 Network Authentication Required, the captive-portal code.

404 vs 410

404 Not Found means the server has no representation for this URI and is not saying why. It might never have existed, it might be a typo, it might come back tomorrow. It is inherently non-committal.

410 Gone means it existed, it was deliberately removed, and it is not coming back. That extra certainty is the entire value. Crawlers treat a 410 as a stronger removal signal than a 404 and generally stop retrying sooner, and clients with a cached copy know to discard it rather than hope. When you genuinely delete content — a retired product, an expired listing, a page taken down on purpose — 410 is the honest answer and the one that gets the URL out of the index fastest.

Where 404 is still right: unknown URLs, mistyped paths, anything you have not decided about. Where neither is right: content that moved. That is a 301, and redirecting a removed page to an unrelated one is worse than either code, because it teaches crawlers that your redirects do not mean anything. The one thing you must not do is serve a “page not found” message with a 200 status — a soft 404 is invisible to every automated check you own.

500 vs 502 vs 503 vs 504

These four look identical to a user and mean completely different things to whoever is on call. The distinction is which machine failed.

502 and 504 both point at the boundary between two systems, and the difference is whether the upstream answered badly or did not answer in time. A 502 that appears the instant you request is usually a dead backend; a 504 that appears after a fixed interval is a timeout, and that interval is a configuration value you can read. Raising the proxy timeout makes 504s disappear without making anything faster — sometimes that is the right call, more often it just moves the pain.

503 is the one class of server error that is meant to be temporary, and it is the correct code for planned maintenance. It should carry a Retry-After header so clients and crawlers know to come back rather than treating the outage as removal. The rest of the class: 501 Not Implemented (the method is unrecognised, not merely disallowed — that is 405), 505 HTTP Version Not Supported, 507 Insufficient Storage, 508 Loop Detected, and 510 Not Extended.

429 and Retry-After

429 Too Many Requests says you have exceeded a rate limit. It is not a failure of your request; it is a statement about your request rate. The critical part is the Retry-After header, which the server may send as either a number of seconds or an HTTP-date, and which tells you exactly how long to wait. A client that ignores it and retries immediately is making the problem worse and will usually be limited harder.

The correct client behaviour is: read Retry-After and honour it if present; otherwise back off exponentially with some jitter, so that a fleet of clients hit by the same limit does not synchronise and retry in lockstep. Cap the number of attempts. Many APIs also expose remaining-quota headers so you can throttle before you get limited at all, and the detail panel for 429 in this tool includes worked retry-with-backoff implementations for JavaScript and TypeScript alongside rate-limiter configurations for Express and Next.js middleware.

Related codes in the same neighbourhood: 408 Request Timeout, where the client was too slow to send its request rather than too fast; 425 Too Early, which refuses a request that risks 0-RTT replay; and 431 Request Header Fields Too Large, which in practice almost always means an oversized cookie.

The codes that trip people up for other reasons

• 400 vs 422: 400 Bad Request is for a request the server cannot parse. 422 Unprocessable Entity is for one that parsed perfectly and is semantically wrong — valid JSON, invalid values. RFC 9110 renames it Unprocessable Content.
• 405 Method Not Allowed: the resource exists but not for this method, and a conforming 405 must include an Allow header listing the ones that work. That header is the answer to your question.
• 201 Created: should carry a Location header pointing at what you just made. 202 Accepted means queued, not done. 204 No Content means success with deliberately empty body — correct for a DELETE.
• 206 Partial Content: the response to a Range request. It is how video seeking and resumable downloads work, and its failure sibling is 416 Range Not Satisfiable.
• 409 Conflict: the request collides with current state — a duplicate unique key, or an edit against a stale version.
• 413, 414, 415: body too large, URI too long, media type unsupported. Each is a limit somewhere in your stack that you can raise, and 413 in particular is often a proxy limit rather than an application one.
• 451 Unavailable For Legal Reasons: blocked for legal rather than technical reasons. The number is a deliberate reference to Fahrenheit 451.
• 418 I’m a teapot: from an April Fools’ RFC in 1998. It is genuinely reserved, genuinely never appropriate in production, and genuinely still implemented all over the place.
• 103 Early Hints: an interim response that lets the browser start preloading assets while the real response is still being generated. Alongside 100 Continue (paired with Expect: 100-continue) and 101 Switching Protocols (the WebSocket upgrade).
• 207 Multi-Status, 422, 423 Locked, 424 Failed Dependency, 507: the WebDAV family. If you are not doing WebDAV, 422 is the only one you will meet.

Checking real URLs in bulk

The second tab takes a list of URLs — one per line or comma-separated, up to 100 at a time — and reports what each one actually returns. Bare hostnames are normalised to https:// automatically. For each URL you get the final status code, its reason phrase, the response time in milliseconds, and the full redirect chain expanded hop by hop, so a URL that goes through three 301s before landing on a 404 shows you all four steps rather than just the last one. It follows up to ten redirects, applies a five-second timeout per request, and runs up to ten checks concurrently. Results export to CSV or JSON.

This tab is the one part of the tool that is not purely local: the checks are performed server-side, because a browser cannot read cross-origin response headers or observe a redirect chain without following it opaquely. Requests are sent with HEAD where the server supports it, and identify themselves honestly in the User-Agent. The reference tab, by contrast, is entirely static data in the page — searching and filtering send nothing anywhere.

One note on RFC references. Each entry cites the specification that defined it, and for most core codes that is the RFC 7230–7235 series. Those were consolidated into RFC 9110 in 2022, which is now the authoritative document for HTTP semantics; the codes and their meanings did not change, and a handful of reason phrases were retitled — 413 to Content Too Large, 422 to Unprocessable Content. Codes defined outside the core series keep their own references: RFC 6585 for 428, 429, 431 and 511; RFC 7538 for 308; RFC 7725 for 451; RFC 8297 for 103; RFC 4918 for the WebDAV codes.