ByteScope

HTTP Status Codes

What each HTTP status code means — and what the front end, the back end and the visitor each do about it.

Your files never leave your browser — all processing is local.

Start from the code you were handed. Every page separates what the specification says from what you actually do about it, and answers the front end, the back end and the person who just wanted the page to load as three different questions.

Filter by class
CodeNameClassWhat it means
301Moved Permanently3xxThe old URL is retired and the one in `Location` replaces it — and because a 301 is one of the few responses a cache may store without being told to, a 301 sent by mistake is the hardest redirect to take back.
302Found3xxA temporary detour: the resource still belongs at the URL you asked for, but for now the server wants this request served from somewhere else — and your browser will take the detour without ever showing it to your code.
304Not Modified3xxYour copy is still good: you sent a validator with the request, the server compared it against the one it holds, they matched, and it deliberately sent headers and no body.
400Bad Request4xxThe server refused to interpret the request at all — something in the request line, a header, the framing or the body is malformed or oversized — which usually means none of your application code ever ran.
401Unauthorized4xxThe request carried no usable authentication credentials — the reason phrase says Unauthorized, but the condition it describes is unauthenticated, and the header naming what would work is mandatory.
403Forbidden4xxThe server understood the request perfectly well and is refusing to carry it out — and unlike a 401, it owes you no header explaining what would have worked.
404Not Found4xxThe server understood the request and has nothing to serve at that path — which on a modern stack is far more often a routing or deployment mistake than a dead link.
405Method Not Allowed4xxThe path exists and the server recognises the verb — it just does not accept that verb here, and it is required to hand you the list of verbs it does accept.
429Too Many Requests4xxA rate limiter has decided you are asking too often — a policy statement rather than a protocol one, which is why two services answering 429 may be counting entirely different things.
500Internal Server Error5xxThe application itself ran, hit something it did not expect, and gave up — so unlike a 502 or a 504 there is a stack trace somewhere, and the whole job is finding which log holds it.
502Bad Gateway5xxA proxy in front of the application answered on its behalf, because the application's own answer was missing, truncated or not valid HTTP.
503Service Unavailable5xxSomething decided not to serve you, on purpose and for now — a maintenance page, a rate limiter or a load balancer with nothing healthy to send you to — which makes 503 the only 5xx that comes with an expiry date.
504Gateway Timeout5xxA proxy waited for an upstream, ran out of patience and answered on its behalf — so the number that identifies the culprit is not the status code but the elapsed time, which is always somebody's configured timeout.
521Web Server Is DownNon-standard5xxCloudflare's own code, not an IETF one, for the narrowest failure in the whole 5xx range: your origin actively refused Cloudflare's TCP connection, so nothing was slow and nothing was misrouted — something said no.
524A Timeout OccurredNon-standard5xxCloudflare's own code for a request that got all the way in and then went quiet: the connection succeeded, the origin received it, and 125 seconds later there was still no HTTP response to send back.

About this tool

Written for the moment somebody hands you a number Almost nobody looks up a status code out of curiosity. They look it up because a deploy went out and half the requests turned red, because a client is reporting an error nobody can reproduce, or because a monitoring alert quoted three digits and nothing else. So every page here leads with what the code tells you about *where* the failure is, and only then explains what the specification says. The definition is the short part; deciding whether to look at your router, your proxy or your upstream is the part that takes the afternoon.

Three readers, three different answers A 404 seen by a front-end developer is usually a route that works on click and breaks on refresh. The same 404 seen by a back-end developer is usually a proxy prefix that was added or stripped before the application saw the path. Seen by a visitor it is a link that has moved. Those are three problems with three fixes, and a page that merges them into one paragraph helps none of the three — so every code here answers them separately, and says plainly when the honest answer for one of them is that there is nothing to do.

Standard, vendor-specific, or just habit RFC 9110 defines the status codes every conforming client and server agrees on, and a few widely used ones live in their own documents — 429 in RFC 6585, 308 in RFC 7538. Plenty of codes you will meet in production are in neither: 499 comes from nginx's source, and the whole 520-526 range is Cloudflare's, invented so that a failure between the edge and your origin is not reported as a generic 502. Each page says which of the three it is, because the difference decides whose documentation is the authority — and this site runs on Cloudflare, so the 52x pages are written from the same side of that connection you are on.

Frequently asked questions

What do the HTTP status code classes mean?

The first digit is the whole classification. 1xx is informational and rarely surfaces in application code; 2xx means the request succeeded; 3xx means further action is needed, usually following a redirect; 4xx means the request itself was faulty; and 5xx means the server failed while apparently handling a valid request. RFC 9110 also says a client that meets an unrecognised code must treat it as the x00 of its class, which is why an unknown 599 is safe to handle as a 500.

How do I see which status code a page actually returned?

In a browser, open the developer tools network panel and read the Status column on the request itself rather than on the assets it pulled in. From a terminal, curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/page prints just the number, and adding -D - prints the response headers with it. The terminal answer is the one to trust when the two disagree: an extension, a service worker or a cached response can change what the browser shows you.

Is a 4xx my fault and a 5xx the server's?

That is the intent of the split, but it is a rule of thumb rather than a guarantee. Plenty of 4xx responses are produced by a server that is misconfigured — a 404 from a proxy that mangled the path, or a 403 from a rule nobody meant to apply — and plenty of 5xx responses are triggered by a request that asked for too much. Use the class to decide which side to look at first, not to decide who is to blame.

Which of these codes are not actual standards?

418 is a joke from an April Fools' RFC that servers still return. 499 is not registered with IANA at all: it comes from nginx and means the client closed the connection before the server answered, so it shows up in your access log rather than in a browser. The 520 to 526 range is Cloudflare's own, and only Cloudflare's documentation defines it. 429, despite feeling like an addition, is a real standard — RFC 6585 — as is 308, from RFC 7538.

Do status codes affect SEO?

Some of them decisively. A 301 passes ranking signals to the new URL while a 302 tells a crawler the move is temporary and to keep the old one, so using 302 for a permanent move quietly costs you. A 404 invites re-crawling for a while, whereas a 410 tells an indexer the resource is finished. The worst case is a soft 404 — an error page served with a 200 — because a search engine then indexes the apology as content.