HTTP Status Code Lookup

A status code is the server's one-number verdict on a request, and it is usually the fastest route to the cause of a failure. It tells you whether to look at the request you sent, the application that handled it, or something standing in between. The lookup above turns the number into that answer.

How it works

Type a code (503), the start of one (40 lists 400 to 409) or part of a name (timeout, gateway), or pick a class with the buttons. Click any entry to see what it means. For the codes that turn up most often while debugging, such as 401, 404, 429, 500 and 502 to 504, the panel adds what usually triggers the code, how to fix it, and the related codes worth checking next. Every entry names the RFC that defines it, so you can go to the source when a detail matters.

The list covers every permanent entry in the IANA HTTP Status Code Registry, including 418, which the registry reserves because the joke RFC made it too widely used to reassign. Nothing you type leaves your browser.

Finding the status code in the first place

Error pages often hide the real number behind a friendly message, so read it from the response itself:

• Browser. Open developer tools, go to the Network panel and reload. Each request shows its status. Filter by status-code:500 in Chrome, or sort the column to bring failures together.
• Terminal. curl -i prints the status line and headers above the body. To get just the number, which is handy in scripts and health checks, discard the body:

curl -s -o /dev/null -w '%{http_code}\n' https://example.com/api/orders

curl -I is tempting but sends a HEAD request, and some servers answer HEAD differently from GET. When the two disagree, trust the method your application actually uses.

A triage order that saves time

Start with the first digit. A 4xx says the server believes the request is at fault, so check the URL, the method, the credentials and the body before touching the server. A 5xx says the server failed at something it should have handled, and the explanation is in its logs, not in the response.

Then ask who produced it. A 502 or 504 is rarely written by your application. It comes from the proxy, load balancer or CDN in front of it, reporting that the application never answered properly. The Server header and the style of the error page usually give the layer away. Restart or scale the upstream service, and check the proxy's timeout, before searching application code.

Watch for codes that are not in the registry. Some infrastructure invents its own. Nginx logs 499 when the client hung up before the response was ready, and Cloudflare returns 520 to 526 for origin connection and TLS problems. The lookup reports them as unknown, which is itself the clue: look up that vendor's documentation, not the HTTP specification.

Retrying safely

Not every failure deserves a retry, and not every request is safe to repeat:

• 429 and 503 are invitations to come back later. If the response carries Retry-After, wait at least that long. Otherwise back off exponentially, with jitter, so a fleet of clients does not retry in lockstep.
• 502 and 504 are often transient, but only retry automatically if the method is idempotent (GET, HEAD, PUT, DELETE). A timed-out POST may already have created the order, so retrying blindly can create it twice. Idempotency keys exist for exactly that case.
• Most other 4xx codes will fail identically on every attempt. Retrying a 400, 403 or 422 only adds load. Fix the request instead.

Learn more

HTTP Status Codes: A Complete Reference explains every class in depth, including redirect and caching semantics and the pairs that are easy to mix up. If you are choosing codes for your own API rather than decoding someone else's, read REST API Design. When a 401 involves a bearer token, the JWT decoder shows whether it has expired or targets the wrong audience, and the URL encoder catches the badly escaped query strings behind many 400s.