HTTP Status Codes

How to use this HTTP status code reference

1. Type a status code (like 404) or a keyword (like "not found").
2. Matching codes appear instantly with their name and meaning.
3. Leave the search empty to browse the full list.

What do the status code ranges mean?

2xx means success, 3xx means redirection, 4xx means a client-side error (like a bad request or missing page), and 5xx means a server-side error. This grouping lets you quickly diagnose what category of problem you're dealing with.

301, 302, 307, and 308 — the redirect codes that confuse almost everyone

The redirect status codes look interchangeable at a glance but actually differ along two genuinely important, independent dimensions. The first is permanence: 301 and 308 mean "permanently moved" (search engines update their index to the new URL, and browsers may cache the redirect long-term), while 302 and 307 mean "temporarily moved" (the original URL should still be treated as the canonical one going forward). The second dimension is method preservation: 301 and 302 technically allow — and in practice, many browsers historically do — changing a POST request into a GET request when following the redirect, silently dropping the original request body, while 307 and 308 strictly guarantee the original HTTP method and body are preserved exactly. This second distinction matters enormously for API redirects specifically, where silently converting a POST into a GET can cause a request to fail or behave completely differently than intended.

Why returning 200 with an error message in the body is a real anti-pattern

A surprisingly common but genuinely problematic API design mistake is always returning HTTP 200 OK, even for requests that actually failed, and putting error information only inside the JSON response body instead. This breaks a large amount of standard, expected HTTP infrastructure that specifically relies on the status code alone to determine success or failure — caching layers, monitoring and alerting systems, retry logic in HTTP clients, and load balancer health checks all typically inspect the status code first, without necessarily parsing the response body at all. An API returning 200 for a failed request means all of that infrastructure incorrectly treats the request as successful, which is exactly why using the semantically correct 4xx or 5xx status code for actual failures — with details in the body as a supplement, not a replacement — is considered standard, correct REST API design rather than an arbitrary stylistic preference.

Status codes and idempotency — why 409 exists specifically

Some HTTP status codes exist specifically to communicate information about idempotency — whether making the same request multiple times produces the same end result as making it once. 409 Conflict is a clear example: it specifically signals that a request couldn't be completed because it conflicts with the resource's current state (trying to create a user with a username that already exists, for instance), which is meaningfully different information than a generic 400 Bad Request would convey. Understanding which HTTP methods are meant to be idempotent by convention — GET, PUT, and DELETE should be, POST generally isn't — combined with specific status codes like 409 helps API clients correctly decide whether it's actually safe to automatically retry a failed request, or whether retrying risks creating duplicate data or other unintended side effects.

304 Not Modified — the status code that saves bandwidth by sending nothing

304 Not Modified is one of the more unusual status codes because a "successful" 304 response deliberately contains no body at all — it's the server's way of telling a browser "the cached version you already have is still current, don't bother re-downloading it." This works through conditional request headers: a browser that has previously cached a resource sends an If-Modified-Since or If-None-Match header on subsequent requests, and if the server confirms the resource hasn't changed since that time or ETag, it returns 304 instead of resending the full content. This is a deliberate, significant bandwidth optimization built directly into HTTP's caching model — the entire mechanism exists so that a browser can efficiently confirm its cached copy is still valid without needing to re-transfer content that hasn't actually changed at all.

Limitations of this tool

This tool provides a searchable reference of standard, officially registered HTTP status codes and their meanings — it doesn't cover the many non-standard, proprietary status codes some specific platforms and CDNs use for their own internal purposes (like Cloudflare's specific 520-range codes). It also can't tell you why a particular request on your own site or API actually returned a given status code — for that, you'll need to inspect the actual request and server logs, since the same status code can result from many different underlying causes depending on the specific application involved.