Toolvore

HTTP Status Code Reference

Searchable reference of all standard HTTP status codes.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Searches a built-in reference of 62 standard HTTP status codes by number or by wording, with each result colour-badged by class so 4xx and 5xx stand apart at a glance.

How to use it

  1. 1Type a code or a phrase in the search box; the list narrows on every keystroke.
  2. 2Use the badge colour to place the code — blue 1xx, green 2xx, yellow 3xx, orange 4xx, red 5xx.
  3. 3Clear the box to bring back the full list, which is always sorted in ascending numeric order.

Example

Input
gateway
Output
502 Bad Gateway and 504 Gateway Timeout

The filter matches the description text as well as the code and name, so searching "proxy" also returns 305 and 407 — codes you would not have reached by number. Number matching is substring-based rather than a prefix, and the reference covers standard codes only: vendor extensions such as nginx's 499 or Cloudflare's 520–527 are deliberately absent.

What happens to your data

The 62 entries are a constant array compiled into the page's JavaScript, and filtering is a useMemo over that array — this component contains no fetch call whatsoever, so what you type in the search box never leaves the input element. The query lives in component state only, meaning a reload returns you to the unfiltered list with no history of what you looked up.

Last updated August 2026

A log line, a browser console or a webhook that keeps failing usually hands you three digits and a URL, and nothing else. That number is the only clue you get, and the difference between 401 and 403, or 502 and 504, decides whether the next hour goes on your own code or on somebody else's server.

Before looking anything up, settle the class. The first digit carries most of the meaning: 4xx says the server understood the request perfectly well and is refusing what you sent, so the fix is on your side; 5xx says the request was reasonable and something broke behind it, so the fix is on theirs. That one split routes more debugging than any individual code does, and getting it the wrong way round is the usual mistake — often because an API returns 500 for what is really a validation failure, sending you into infrastructure that was never at fault.

The second thing worth knowing is that a status code is not an error message. It is a coarse, machine-readable category with a fixed meaning, and the detail lives in the response body and headers. A 400 will not tell you which field was wrong, and a 429 will not tell you when to try again unless a Retry-After header came with it. Read the code to learn what kind of answer you got, then read the body to learn why.

Not every number in a log is standard either. Reverse proxies and CDNs mint their own, and those belong to the product that emitted them rather than to HTTP.

How it works

Toolvore holds all 62 codes as a constant array compiled into the page, so the search box is a filter rather than a lookup. On every keystroke your text is lowercased and trimmed, and an entry survives if the digits appear anywhere in its number, or the phrase appears anywhere in its name, or anywhere in its one-line description. That third test is what earns its keep: searching for proxy returns 305 and 407. Number matching is substring rather than prefix, so typing 04 brings back 204, 304, 404 and 504 together. The colour badge is arithmetic on the code alone — the hundreds digit and nothing else — which is why blue, green, yellow, orange and red line up exactly with 1xx to 5xx. The weakness is the same as the simplicity. The list is standard codes only, each description is a single sentence rather than the specification's full wording, and there is nothing here that fetches a URL: it tells you what a code means, never what your server is returning right now.

Common use cases

  • Working out whether a failing request is your fault or the server's
  • Choosing the right code to return from an API endpoint you are writing
  • Reading a run of numbers out of an access log or a monitoring alert
  • Settling whether a redirect should be 301, 302, 307 or 308
  • Explaining a failure to a colleague who only has the number from a browser
  • Checking what a client library means by the error it just raised
  • Sanity-checking expected codes before writing test assertions

Frequently asked questions

What is the difference between 401 and 403?

Both are refusals, and the difference is about identity. 401 Unauthorized is misnamed: it means authentication is required and has either failed or not been supplied, so the answer is to log in, refresh the token or fix the credential — and a correct 401 arrives with a WWW-Authenticate header naming the scheme. 403 Forbidden means the server understood the request and knows who you are, and is refusing anyway. Better credentials will not help; you need different permissions or a different account. In practice some servers return 403, or even 404, rather than confirm that a resource exists — defensible as security, maddening while debugging.

Should a redirect be 301 or 302?

301 Moved Permanently declares the new address is the address from now on, and browsers cache it hard — sometimes long past the point you wish they would. 302 Found says the move is temporary and the original URL still matters. The trap is that both were historically allowed to turn a POST into a GET when following the redirect, which is exactly why 307 Temporary Redirect and 308 Permanent Redirect exist: they preserve the method and the body. Use 301 for a genuine migration, 302 for a short diversion such as maintenance, and 307 or 308 whenever a form submission or an API call is what is being redirected.

What causes a 502 Bad Gateway or a 504 Gateway Timeout?

Both come from something sitting in front of the real server — a load balancer, a reverse proxy, a CDN. 502 Bad Gateway means that intermediary received a response from upstream but could not make sense of it, typically an application that crashed part-way through replying. 504 Gateway Timeout means nothing came back in time at all: a slow query, a hung worker, a pool with no free connections. As a visitor there is little to do beyond reloading once and waiting. As an operator, the cause is in the proxy's own log rather than the application's, because the application may never have been reached.

Why do I keep getting 429 Too Many Requests?

429 means a rate limit has been crossed — per key, per IP, per account or per endpoint, and rarely the same window on any two APIs. The response should carry a Retry-After header giving seconds or a date, and honouring it is most of the answer. When it is absent, back off exponentially with some jitter rather than on a fixed timer, because synchronised clients push a struggling service straight back over the line. Check whether the limit is really yours, too: shared office addresses, CI runners and pooled serverless functions all trip limits that look unfair from a single machine.

When should a missing page return 410 instead of 404?

404 Not Found means there is nothing at that address and there might be later; 410 Gone is the stronger claim that something existed, was removed deliberately and is not returning. Search engines act on the difference, dropping a 410 sooner. The costlier mistake is the soft 404 — a missing page that answers 200 with a friendly apology in the body. Every crawler and uptime check then believes the page is healthy, and broken links go unreported for months. If a page is missing, the status line has to say so, whatever the page itself looks like.

Is 422 the right code for a validation error, or 400?

400 Bad Request is the general refusal: the server could not parse the request or would not process it — malformed JSON, a missing parameter, a header it cannot accept. 422 Unprocessable Entity is narrower: the syntax was fine and the request understood, but the content broke a rule, such as an email that is not an email. Frameworks differ wildly, some using 422 for every validation failure and some never emitting it at all, so consistency inside your own API matters more than the theoretically perfect choice. Either way the body has to name the offending fields, because neither number can.

What are status codes like 499, 520 and 522?

Strictly they are not HTTP status codes at all; they belong to the software that emitted them. nginx writes 499 into its log when a client hangs up before the response is finished, which is a note to the operator rather than anything a browser sees. Cloudflare's 520 to 527 describe failures between its edge and your origin — 521 for an origin refusing connections, 522 for a connection timeout, 525 for a TLS handshake failure. Being vendor extensions, they are documented only by that vendor, and the same number can mean something different behind a different proxy. Search the product's documentation, not the HTTP specification.

Does what I type in the search box go anywhere?

Nowhere. The 62 entries are a plain array compiled into the page's JavaScript, and filtering is a computation over that array in your browser — the component contains no fetch call at all, so nothing is sent as you type. The query is held in ordinary component state, so a reload clears it and brings back the full list with no record of what you searched for. That is worth knowing because a status-code lookup is often the first thing typed while an incident is live, and the codes someone reaches for at that moment say a good deal about what is currently broken.

Used in these workflows