HTTP Status Codes, Explained

Every HTTP response starts with a three-digit number, and that number is trying to tell you something before you even look at the response body. The first digit sorts responses into five broad classes, and knowing just that digit tells you who's likely at fault: your code, the server on the other end, or nobody, because everything worked fine.

1xx codes are informational: the server acknowledged the request and is still working, and you'll rarely see these outside of low-level HTTP tooling. 2xx means success: the request did what it was supposed to do. 3xx is redirection: the resource you asked for lives somewhere else now, follow the pointer. 4xx is a client error: something about the request itself was wrong, usually before it ever reached whatever logic was supposed to handle it. 5xx is a server error: your request was probably fine, but the server choked trying to fulfill it.

That five-way split is worth memorizing on its own, separate from any individual code. See a 4xx in your logs and the fix is almost always on the request side: bad auth, malformed JSON, a typo'd endpoint. See a 5xx and the fix is on the server: a crashed process, a database timeout, a misconfigured proxy. You can triage a lot of incidents just from that first digit before reading a single line of the stack trace.

200 OK, and why 301 vs 302 is more than pedantry

200 OK is the one nobody thinks about because it's the default outcome — the request worked, here's your data. It's worth mentioning mainly because of how often it gets misused. Some APIs, including a few widely-used payment and messaging platforms, return 200 for requests that actually failed, tucking the real error into a JSON field like "status": "error" inside the body. That's an anti-pattern worth knowing about specifically because it breaks every tool that trusts the status code: your monitoring won't alert, your retry logic won't retry, and your uptime checks will report green while the feature is actually broken. If you're building an API, let the status code carry the truth. If you're consuming one, don't assume 200 means success without checking the payload too.

301 and 302 both mean "go here instead," and mixing them up is a genuinely expensive mistake, not a cosmetic one. 301 Moved Permanently tells browsers and search engines the old URL is gone for good — bookmarks should update, and crawlers transfer the old page's ranking signals to the new address. 302 Found means the move is temporary: keep the original URL indexed, keep pointing bookmarks there, this is just a detour. Use a 301 for a real URL migration (a redesign, a domain change) and a 302 for something genuinely short-lived (maintenance mode, A/B testing, a login wall). Slap a 301 on a temporary redirect and you can watch your rankings quietly migrate to a URL you meant to delete in a week. There's also 307 and 308, which behave like 302 and 301 respectively but guarantee the request method doesn't change on redirect — useful if you're redirecting a POST and don't want it silently turned into a GET.

400 vs 401 vs 403: the trio everyone mixes up

These three get confused constantly, and the confusion usually comes from thinking of them as a severity scale rather than three different questions. They're not ranked from mild to severe. Each one is answering something specific about the request.

400 Bad Request means the server couldn't even parse or validate what you sent: malformed JSON, a missing required field, a query parameter of the wrong type. This has nothing to do with who you are; it's purely about the shape of the request. 401 Unauthorized is the one people get backwards most often: despite the name, it's really about authentication, not authorization. It means the server doesn't know who you are at all, no credentials were sent, or the ones you sent are invalid or expired. What does 403 mean, then? 403 Forbidden means the server does know exactly who you are; your token or session checked out fine. It's just decided you're not allowed to do this specific thing. Trying to open someone else's private document while correctly logged in as yourself is the textbook 403. Trying to access an endpoint with no login at all is the textbook 401.

The distinction matters for how you debug it. A 401 means go check your auth flow: expired token, missing header, wrong API key. A 403 means your auth is fine and you need to check permissions instead: roles, ownership, scopes. Confuse the two while debugging and you'll waste time staring at a token that was never the problem.

404, 429, and the 500 family

404 Not Found is the famous one, and it's exactly what it sounds like: nothing lives at this URL, and the server isn't going to tell you why or where it went (that's what 410 Gone is for, when a resource was deliberately removed rather than never existing). 429 Too Many Requests is the rate-limiting response, and it shows up more and more as APIs get stricter about abuse: you've sent more requests than the server allows in a given window, and the fix is to slow down, ideally by reading the Retry-After header the server usually includes rather than guessing at a backoff interval.

Then there's the 500 family, another commonly confused trio, and again the confusion comes from not asking who's actually broken. 500 Internal Server Error is a catch-all: something unexpected happened inside the server handling your request, and the fault is squarely with that server. 502 Bad Gateway means the server you talked to is actually a proxy or load balancer, and it got a garbage or unreadable response from the actual application server sitting behind it — the fault is one hop further back than the server that answered you. 503 Service Unavailable means the server is up and reachable but deliberately not handling requests right now, usually because it's overloaded or down for maintenance; it's often the most temporary of the three and frequently comes with a Retry-After header too.

Worth a mention since it comes up constantly in trivia and rarely anywhere else: 418 I'm a Teapot is real, and it's still a technically valid status code you can return from a production server today. It originated in RFC 2324, an April Fools' RFC from 1998 called the "Hyper Text Coffee Pot Control Protocol," describing how a teapot receiving a request to brew coffee should refuse with 418. It was a joke, and it stuck around in the spec long enough that some frameworks and even a few real APIs use it deliberately as an easter egg or a deliberately absurd rejection code. Harmless, and a decent reminder that status codes are a convention people agreed on, not a law of physics.

Try it

GlaeKit's HTTP Status Code Lookup has the full list, searchable by code or keyword, so you don't have to memorize the trickier ones. Nothing is sent to a server.

Frequently asked questions