📡 HTTP Status Codes

A searchable reference of every standard HTTP status code, with meanings and common causes.

1xx

Informational

The request was received and the process is continuing.

2xx

Success

The request was successfully received, understood, and accepted.

3xx

Redirection

Further action is needed to complete the request.

4xx

Client Error

The request contains bad syntax or cannot be fulfilled.

5xx

Server Error

The server failed to fulfil an apparently valid request.

About HTTP Status Codes

Every HTTP response begins with a three-digit status code that tells the client how the request turned out. The first digit defines one of five classes: 1xx informational, 2xx success, 3xx redirection, 4xx client errors, and 5xx server errors. Knowing them well is essential for debugging APIs, tuning caching and redirects, and diagnosing production incidents quickly.

This reference lists all standard codes defined by the IETF (RFC 9110 and related specs), plus the widely-used WebDAV and extension codes. Use the search box to jump to a code by number or keyword, and expand any card for a fuller explanation and the causes you're most likely to hit in practice.

The five classes at a glance

1xx · Informational

The request was received and the process is continuing.

2xx · Success

The request was successfully received, understood, and accepted.

3xx · Redirection

Further action is needed to complete the request.

4xx · Client Error

The request contains bad syntax or cannot be fulfilled.

5xx · Server Error

The server failed to fulfil an apparently valid request.

Frequently Asked Questions

What's the difference between 401 and 403?

401 Unauthorized means you haven't authenticated (or your credentials/token are missing, expired, or invalid) — authenticating correctly may grant access. 403 Forbidden means you are recognized but simply not allowed to access the resource, so re-authenticating won't help; you lack the necessary permissions.

When should I use 301 vs 302 vs 307/308?

Use 301 (permanent) when a URL has moved for good so search engines transfer ranking; use 302/307 (temporary) when the move is short-lived. The modern 307 and 308 additionally guarantee the HTTP method isn't changed (a POST stays a POST), which 301/302 historically did not, so prefer 308 for permanent and 307 for temporary redirects of non-GET requests.

What does a 502 vs 503 vs 504 tell me?

All three are server-side. 502 Bad Gateway means a proxy got an invalid response from the upstream app (often it crashed or is misconfigured). 503 Service Unavailable means the server is overloaded or in maintenance and is usually temporary. 504 Gateway Timeout means the upstream didn't respond in time — commonly a slow query or a timeout that's too short.

Is 429 the same as being blocked?

No. 429 Too Many Requests means you've hit a rate limit and should slow down — it's temporary. Check for a Retry-After header and add exponential backoff to your client. A permanent block is more likely to surface as 403 Forbidden or 451.

Are all these codes officially standardized?

Most are defined in IETF RFCs (notably RFC 9110). A few — like the 1xx/2xx/4xx WebDAV codes (102, 207, 422, 423) and 418 'I'm a teapot' — come from extensions or are semi-humorous, but all are recognized and used in the wild, which is why they're included here.

HTTP status codes: the classes, the confusable pairs, and how to pick the right one

Every HTTP response opens with a three-digit code, and the first digit carries most of the meaning. 1xx is informational and interim, 2xx means the request succeeded, 3xx means the client must do something more to finish it, 4xx blames the request, and 5xx blames the server. Clients, proxies, CDNs and crawlers all branch on that first digit before anything else, which is why choosing the wrong class does more damage than choosing an imprecise code within the right one.

This page is a searchable catalogue of 61 codes drawn from RFC 9110 and its neighbours, plus the WebDAV extensions and the handful of oddities you still meet in production. They are grouped by class, filterable by class, and searchable by number or keyword. 38 of the entries carry a Common causes list, which is the part you actually want at 2am: not what 502 means, but the three things that usually produce one.

The codes that cause real arguments are not the obscure ones. They are the adjacent pairs: 401 against 403, 301 against 302 against 307 against 308, 409 against 422, 404 against 410. Each pair encodes a distinction that some intermediary depends on, whether that is a browser deciding to re-prompt for credentials, a search engine deciding to transfer link equity, or a client library deciding whether to retry.

The most consequential mistake is not in any of those pairs, though. It is returning 200 with an error described in the body. That tells every cache on the path the response is a valid, storable success, tells retry middleware there is nothing to retry, and makes error rates invisible to any monitoring that reads the status line. Anything that failed should say so in the code.

How it works

The catalogue is a static local dataset, so search is instant and offline. Filtering matches your query against the code number as a substring, the code's name, and its one-line summary. It deliberately does not search the longer expanded text or the Common causes bullets, so searching for nginx or client_max_body_size finds nothing even though that phrase appears under 413. Search by number, by name, or by an obvious keyword like timeout, redirect or rate.

Codes are grouped into 1xx (4 entries), 2xx (10), 3xx (7), 4xx (29) and 5xx (11). The lopsided 4xx count is not an accident of curation: HTTP has genuinely spent thirty years subdividing the ways a client can be wrong, from 411 Length Required through 428 Precondition Required to 451 Unavailable For Legal Reasons, while the server side has stayed at a broad handful. Class filters and the search box combine, so 4xx plus auth narrows to the authentication codes.

Expanding a card reveals the fuller explanation and, where it exists, the causes list. Expansion also feeds that card's full text to the on-page assistant, which otherwise only receives the summaries of the codes your current filter has left on screen. Open the two or three codes you are actually comparing before asking a question about them, and the answer is grounded in this page's text rather than recalled from elsewhere.

Common uses

Settle whether an endpoint should answer 401 or 403 by reading both entries side by side before the API contract is frozen.
Pick between 301 and 308 when moving an API endpoint that receives POST requests, where the difference decides whether bodies survive the redirect.
Look up what a 421 or a 425 in a load balancer log actually means, rather than guessing from the name.
Check the Common causes list for 502, 503 and 504 to narrow down which layer of a proxy chain is failing during an incident.
Decide between 409 and 422 for a validation endpoint so client authors can distinguish retryable state conflicts from bad input.
Confirm whether a code you are about to return is standard at all before it goes into a public API specification.
Explain to a reviewer why a deleted resource should answer 410 rather than 404 when you want it de-indexed quickly.
Search by keyword when you remember the behaviour but not the number, for example typing range, teapot or legal.

Before you rely on the result

This is a reference, not a checker. It does not fetch URLs and cannot tell you what code your server is currently returning; use curl -I, your browser's network panel, or your access logs for that.
A few codes are deliberately absent. 305 Use Proxy and 306 were deprecated and should never be emitted. So are the non-standard ones: nginx's 499 for a client that hung up, and Cloudflare's 520 through 527. If you see those in logs they came from your infrastructure, not from the HTTP specification.
Search does not look inside the expanded detail or the causes bullets, so a phrase you remember reading on a card may return no results from the search box. Filter by class and scan instead.
418 I'm a teapot is a 1998 April Fools' joke that was never a real error code. Several of the WebDAV entries (102, 207, 208, 423, 424, 507, 508) are real but narrow, and returning them from an ordinary REST API will confuse clients that have never seen them.
The status code is a machine-readable signal, not a user-facing message. Pair it with a body that explains the specific failure, ideally in a documented format such as RFC 7807 problem+json, because 400 alone tells a client nothing about which field was wrong.
429 and 503 both mean try again later, and both are much less useful without a Retry-After header. Without it every client has to invent its own backoff, and the usual invention is to retry immediately, which is how a rate limit becomes an outage.