HTTP Status Codes Explained: What Every Number Means

Every response an HTTP server sends back — whether it's a normal web page loading correctly or an API request failing — carries a three-digit status code that tells the requester exactly what happened. Most people only ever notice the ones that go wrong: a 404 when a link is broken, or a 500 when a site is having a bad day. But status codes form a genuinely well-organized system, and understanding it makes debugging a failed request, a broken redirect, or an API integration dramatically faster. This guide covers the five status code classes, a reference table of the codes you'll actually run into, and two distinctions — 401 vs 403, and 301 vs 302 — that trip up even experienced developers.

The five status code classes

Every HTTP status code is a three-digit number, and the first digit alone tells you the general category of what happened, before you even need to know the specific number:

• 1xx — Informational. The request was received and understood, and processing is continuing. These are provisional responses, sent before the final result — you'll rarely see them directly, since browsers and most tools handle them automatically behind the scenes and wait for the real final response.
• 2xx — Success. The request was received, understood, and accepted successfully. This is the outcome every request is really aiming for.
• 3xx — Redirection. Further action is needed to complete the request, almost always meaning "the resource you want has moved — go look over here instead." Browsers generally follow these automatically without the user noticing.
• 4xx — Client error. The request itself has a problem — bad syntax, a resource that doesn't exist, missing or invalid credentials, and so on. The fault sits with the request as sent, not with the server.
• 5xx — Server error. The request was apparently valid, but the server failed to fulfill it anyway. The fault sits with the server, not with anything the client did wrong.

That single first digit is often enough to know where to start debugging: a 4xx means check what you sent (the URL, the headers, the auth token, the request body); a 5xx means the problem is on the receiving end and there's nothing wrong with your request to fix.

The most common status codes, explained

Within those five classes, a handful of specific codes cover the overwhelming majority of what you'll actually encounter day to day:

Code	Class	What it means
200 OK	Success	The request succeeded, and the response body contains the requested data — the default "everything worked" response.
201 Created	Success	The request succeeded and, specifically, a new resource was created as a result — the standard response after a successful POST that creates a new record.
204 No Content	Success	The request succeeded but there's deliberately no body to return — common after a successful DELETE, where there's nothing left to describe.
301 Moved Permanently	Redirection	This resource has permanently moved to a new URL; update your bookmarks/links to point there going forward.
302 Found	Redirection	This resource is temporarily at a different URL right now; keep using the original URL for future requests.
304 Not Modified	Redirection	The client's cached copy is still valid — no need to re-download the content again, saving bandwidth on both sides.
400 Bad Request	Client error	The request is malformed or invalid in some way the server can't process — often a syntax error in the request body.
401 Unauthorized	Client error	The server doesn't know who you are — you're missing valid credentials, or they weren't provided at all.
403 Forbidden	Client error	The server knows who you are, and you're specifically not allowed to access this resource regardless.
404 Not Found	Client error	The server can't find anything at the requested URL at all — the single most familiar status code to non-developers.
405 Method Not Allowed	Client error	The URL exists, but doesn't support the HTTP method you used — e.g. sending a POST to an endpoint that only accepts GET.
429 Too Many Requests	Client error	You've sent more requests than the server's rate limit allows in the current time window; wait and retry.
500 Internal Server Error	Server error	A generic catch-all meaning something broke on the server while handling an otherwise valid request.
502 Bad Gateway	Server error	A server acting as a proxy or gateway got an invalid response from the upstream server it was relying on.
503 Service Unavailable	Server error	The server is temporarily unable to handle the request — often overloaded or down for maintenance.
504 Gateway Timeout	Server error	A proxy or gateway server didn't get a response from the upstream server in time.

Looking up a status code you don't recognize on the fly is often faster than searching around — DocNectar's HTTP Status Code Lookup tool covers the full official list with a plain-language explanation for each one.

401 vs. 403: unauthenticated vs. unauthorized

This pair is one of the most commonly confused distinctions in web development, and the official names ("Unauthorized" for 401, "Forbidden" for 403) don't help much, since "unauthorized" sounds like it should mean "not allowed" — which is actually what 403 means. The clearer way to think about the two:

• 401 Unauthorized really means unauthenticated: the server has no valid credentials for you at all — you didn't log in, your session expired, or your API token is missing or invalid. The fix is to authenticate (log in, refresh the token) and try again.
• 403 Forbidden means the server knows exactly who you are — your credentials are valid and were received just fine — but you specifically don't have permission to access this particular resource. Logging in again won't fix a 403, because the problem isn't your identity, it's your permission level.

A concrete example makes the difference obvious: visiting an admin dashboard while logged out returns 401 (the server doesn't know who you are yet). Logging in as a regular user and then visiting that same admin dashboard returns 403 (the server now knows exactly who you are, and that identity simply isn't allowed in).

301 vs. 302: permanent vs. temporary redirects — and why it matters for SEO

Both 301 and 302 tell a browser "go here instead," and both are typically followed automatically without a user noticing anything happened. The difference is entirely about what the redirect implies for the future:

• 301 Moved Permanently says the original URL's content has moved for good. Search engines treat this as an instruction to transfer the original URL's accumulated ranking signals to the new destination URL, and to update their index to point there directly going forward.
• 302 Found says the content is only temporarily at a different location right now — the original URL is still the "real" one and should keep being used and indexed as such. Search engines generally do not transfer ranking signal to the temporary destination, precisely because the redirect is explicitly saying "this isn't permanent."

Getting this wrong has real, lasting SEO consequences. Permanently retiring an old URL and redirecting it with a 302 instead of a 301 can strand its accumulated ranking history at the old (dead) URL instead of transferring it to the new one — search engines were explicitly told the move was temporary, so they have no reason to consolidate ranking signal onto the new URL. The rule of thumb: if the old URL is never coming back, use 301; if the redirect is genuinely short-lived (a maintenance page, an A/B test, a temporarily unavailable resource), 302 is the correct, honest signal to send.

429: rate limiting explained

429 Too Many Requests exists to protect a server from being overwhelmed by any single client sending requests faster than a defined limit allows — whether that client is a legitimate application calling an API too aggressively, or something abusive like a scraper or brute-force script. When a server's rate limit is exceeded, it returns 429 instead of processing the request, often alongside a Retry-After header telling the client exactly how long to wait before trying again. Rate limiting protects shared infrastructure from any one consumer degrading service for everyone else, and well-behaved API clients are expected to detect a 429, back off, and retry after the indicated delay rather than immediately hammering the endpoint again.

Frequently asked questions

What's the difference between 404 and 410?

404 Not Found simply means nothing was found at this URL, with no claim about whether it ever existed or might come back. 410 Gone is a stronger, deliberate statement that the resource used to exist here and has been intentionally, permanently removed — a small but real signal difference that some search engines treat as a hint to de-index the URL faster than they would for a plain 404.

Why do I sometimes see a 200 status code even though the page shows an error message?

This happens when an application handles an error at the application level but still returns a successful HTTP status, because the HTTP request to load the page technically succeeded — the "error" is just content within a normally delivered page, not a failure of the HTTP request itself. It's generally considered better practice for an API to return an accurate error status code (like 400 or 404) rather than 200 with an error message buried in the body, since the latter forces every client to inspect the response body just to know whether the request actually worked.

Is a redirect chain (301 to 301 to 301) a problem?

It can be — each hop in a redirect chain adds latency, and search engines historically have followed only a limited number of redirect hops before giving up. It's best practice to update links to point directly at the final destination rather than letting multiple redirects stack up over time as URLs change repeatedly.

Does every 5xx error mean the server is completely down?

No — 5xx just means the server failed to complete this specific request, for any reason: an unhandled exception in application code, a database timeout, an upstream dependency failing, or genuine downtime. A server can be otherwise healthy and responsive while still returning a 500 for one specific request that hit a bug or a transient failure.

Look up any status code

DocNectar's HTTP Status Code Lookup covers the complete official list of status codes with a plain-language explanation for each, useful any time an unfamiliar three-digit number shows up in your network tab or server logs.