HTTP-statuskoder

A complete, searchable HTTP status codes reference

This HTTP status codes reference puts every standard code in one searchable place. Type a number like 404, a name like unauthorized, or a keyword like redirect, and the matching codes appear instantly with a plain-English meaning. Each entry shows its class colour, the official RFC reference, and — for errors — the common causes and how to fix them.

Unlike static list of HTTP status codes pages, this is interactive: filter by class, flip to a compact cheat sheet, or jump straight to a single code. Because the whole dataset ships with the page, lookups are instant and work offline. No sign-up, no rate limits, no ads loading before you can see the answer.

The five classes of HTTP status codes

Every code falls into one of five classes set by its first digit. 1xx Informational means the request was received and is continuing (100 Continue, 101 Switching Protocols). 2xx Success means it worked (200 OK, 201 Created, 204 No Content). 3xx Redirection sends you elsewhere (301, 302, 304, 307, 308).

4xx Client error means your request is wrong (400, 401, 403, 404, 429), and 5xx Server error means the server failed (500, 502, 503, 504). Knowing the class tells you who's at fault before you even read the code: a 4xx is yours to fix, a 5xx is the server's. That single distinction is the most useful thing to know about HTTP error handling — it tells you where to look before you dig into logs.

The most common HTTP status codes and what they mean

A handful of codes cover almost everything you'll see while building or debugging the web. On the success side, 200 OK and 201 Created confirm requests worked. Among redirects, 301 (permanent) and 302 (temporary) are the main pair, with 304 Not Modified powering browser caching.

Among client errors, 400, 401, 403, 404 and 429 dominate; among server errors, 500, 502, 503 and 504. Toggle 'Common only' above to filter the full registry down to this important shortlist, with causes and fixes for each one.

4xx vs 5xx: client errors versus server errors

The difference between 4xx and 5xx errors tells you where to look. A 4xx is a client error — the request is malformed, unauthenticated, forbidden, or pointed at a missing resource — so resending it unchanged won't help. Read the response body and headers, fix the request, then retry.

A 5xx is a server error — your request may be valid but the server couldn't fulfil it. A 500 usually means an unhandled exception, a 502 means a dead upstream behind a proxy, and a 503 means temporary overload or maintenance. For 5xx, the fix lives in server logs, not your request. This also means retry logic should only apply to 5xx responses, with exponential backoff — retrying a 4xx just burns request quota for no benefit.

Cloudflare 5xx codes (520–530) you won't find in the spec

If your site sits behind Cloudflare, you'll meet a family of non-standard 5xx codes the official HTTP spec never defines. 520 means the origin returned an empty or unexpected response, 521 means the origin refused the connection (it's offline or firewalling Cloudflare's IPs), 522 is a TCP connection timeout, 523 means the origin is unreachable (often bad DNS), and 524 means the origin connected but didn't reply within Cloudflare's 100-second window.

The SSL group — 525 SSL Handshake Failed and 526 Invalid SSL Certificate — shows up when the certificate on your origin is missing, expired, or doesn't match Cloudflare's Full (Strict) mode. 530 almost always travels with a 1xxx error in the body, usually an origin DNS failure (Error 1016). Most reference sites omit these codes entirely, which is exactly why developers end up searching for them mid-incident — they're searchable here with the same causes-and-fixes treatment as the standard codes.

How this compares to MDN, httpstatuses.com, and other references

The most-used alternative for HTTP status code lookups is MDN Web Docs. MDN's coverage is thorough and authoritative, but you navigate one page per code — there's no search bar that filters across all codes at once, no class filter, and no compact cheat-sheet mode. If you already know you're looking at a 429 and want its spec definition, MDN is excellent. If you're debugging a number you've never seen, a searchable reference is faster.

httpstatuses.com shows codes in a colour-coded grid with short descriptions but doesn't explain common causes or how to fix errors. restapitutorial.com and w3schools both cover HTTP codes in static tables without filtering. HTTP.cat is a fun meme site (each code maps to a cat photo) but impractical for real debugging. This tool combines live search, filter by class, cheat-sheet mode, causes, fixes, Cloudflare 5xx codes, and RFC links — all in one page that runs offline with no ads.

HTTP status codes and SEO

Status codes quietly shape how search engines crawl and rank a site. Every page you want indexed should return 200 OK. When you change a URL permanently, use a 301 Moved Permanently so ranking signals follow it; use 302 only for temporary moves so the original URL keeps its authority.

For removed content, 404 Not Found and 410 Gone both drop a page from the index — 410 faster, because it promises the resource is permanently gone. During planned downtime, return 503 Service Unavailable with a Retry-After header so crawlers come back later instead of de-indexing your pages. Getting these codes right is one of the cheapest wins available during site migrations — it takes minutes to configure, and the SEO impact is immediate.

1xx, 2xx, and 3xx codes in depth: the complete success and redirect picture

The 1xx Informational class is the HTTP protocol talking to itself. 100 Continue exists to avoid wasted bandwidth: when a client wants to send a large request body, it first sends the headers alone with an Expect: 100-continue header; the server replies 100 if it's willing to accept the payload, or a 4xx error to reject it before the body arrives. 101 Switching Protocols is the handshake that powers WebSocket connections — the browser sends an Upgrade: websocket header, and 101 confirms the server is switching from HTTP to the WebSocket protocol on that same TCP connection. You will rarely write code that generates 1xx codes, but understanding them explains why your WebSocket library works the way it does.

Within the 2xx Success class, the codes communicate different shapes of success. 200 OK is the broadest success — for a GET it returns the resource, for a POST it returns whatever the action produced. 201 Created is narrower: it signals that a POST or PUT specifically created a new resource, and the server should include a Location header pointing to it (e.g., Location: /users/42). 204 No Content means success but there is intentionally no response body — the right choice for a DELETE endpoint or a PUT update where the client has no need to see the result. 206 Partial Content is the backbone of media streaming and resumable downloads: when a client sends a Range: bytes=0-1048575 header, the server replies 206 with just that chunk of the file, enabling video players to seek without downloading from the beginning.

The 3xx Redirection codes form a precise vocabulary for telling clients where to go. 301 Moved Permanently and 308 Permanent Redirect both signal a forever move; the difference is that 301 historically allowed browsers to downgrade a POST to a GET on the new URL, while 308 guarantees the original method is preserved. Similarly, 302 Found and 307 Temporary Redirect both signal a temporary move, but 307 locks in the method. In practice: use 301 for page URL changes, use 308 when redirecting a form's POST target permanently. 304 Not Modified is not really a redirect — it's the server telling the browser during a cache validation request that its cached copy is still current, so no body is sent, saving bandwidth. A browser sends an If-None-Match or If-Modified-Since header; if the resource is unchanged, the server replies 304 and the browser serves from its local cache.

The critical 4xx and 5xx codes every developer must know

Within the 4xx client error class, several codes are consistently misused or misunderstood. 400 Bad Request is the correct response when the request is syntactically malformed — invalid JSON, a missing required query parameter, or a field with the wrong data type. 401 Unauthorized is poorly named: it actually means unauthenticated. The request lacks valid credentials, and the server should reply with a WWW-Authenticate header describing how to authenticate; if you provide a valid token, the same request can succeed. 403 Forbidden means you are authenticated but not authorized — you've proved who you are and the server knows it, but your account doesn't have permission. Providing different credentials won't help; you need different permissions. 405 Method Not Allowed is specific: the endpoint exists but doesn't support the HTTP method you used. A GET /users endpoint that only accepts POST will return 405 and must include an Allow header listing the accepted methods.

408 Request Timeout means the server closed the connection because the client took too long to send the complete request — common on slow mobile connections or large file uploads. 409 Conflict signals a state conflict: the request is valid but can't be completed given the current state of the resource — the canonical example is creating a resource that already exists (duplicate username, conflicting calendar booking). 410 Gone is the explicit alternative to 404: it tells crawlers and clients that the resource existed, was deliberately removed, and will never come back. Search engines remove a 410 page from their index faster than a 404 because 404 could be a temporary glitch. 422 Unprocessable Entity covers semantically valid requests that fail business logic validation — the JSON is well-formed and the request is authenticated, but the values themselves are invalid. 429 Too Many Requests is the rate-limiting code; it should always include a Retry-After header giving the number of seconds or an HTTP-date after which the client may retry.

In the 5xx server error class, the nuances matter for debugging. 500 Internal Server Error is the catch-all for unhandled exceptions — check your server logs for a stack trace. 502 Bad Gateway means a reverse proxy (Nginx, a load balancer, a CDN edge node) received an invalid response from your upstream application server — the app process likely crashed or returned garbage. 503 Service Unavailable signals the server is temporarily unable to handle requests due to overload or planned maintenance; include a Retry-After header so clients and crawlers back off gracefully rather than hammering the server. 504 Gateway Timeout differs from 502 in that the upstream server was reachable but simply didn't respond within the proxy's timeout window — a slow database query or an unresponsive microservice is often the cause. When on-call, the sequence to check is: 500 → app logs, 502 → is the app process alive, 503 → is the server under load or in maintenance mode, 504 → what upstream call is hanging.

HTTP status codes in REST API design: conventions that matter

REST API design hinges on using status codes to carry meaning that would otherwise bloat the response body. The 200 vs 201 distinction is the most commonly skipped convention: a POST /users endpoint that creates a user should return 201 Created with a Location: /users/42 header, not 200. Returning 200 for every successful response forces API consumers to inspect the body to understand what happened, which makes programmatic error handling harder and breaks tools that rely on HTTP semantics — monitoring dashboards, API gateways, and integration tests all work better when status codes carry the right meaning. Stripe, GitHub, and Twilio all follow this convention precisely, and their SDKs benefit from it.

The 204 vs 200 for DELETE question is a real design decision. 204 No Content signals clean deletion with no body — the absence of a body is itself the confirmation, and HTTP clients handle it efficiently. Some teams prefer returning 200 with a JSON body like {"deleted": true, "id": 42} to give frontend clients explicit confirmation without requiring them to trust a missing body. Neither approach violates the spec, but 204 is the more idiomatic REST choice, and mixing the two across endpoints in the same API creates confusion. Pick one and document it. A subtlety: if you return 204 for a resource that was already gone, that's correct — idempotent DELETE means calling it twice should not return 404 on the second call.

The 422 vs 400 boundary for validation errors has effectively been settled by major API providers. 400 Bad Request should mean the request was syntactically malformed — unparseable JSON, wrong Content-Type, missing required HTTP headers. 422 Unprocessable Entity should mean the request was well-formed but semantically invalid — an email field that isn't a valid email, a date range where end is before start, a reference to a foreign key that doesn't exist. Stripe, GitHub, and most modern REST APIs return 422 for validation errors, pairing it with a structured error body listing the offending fields. The alternative — returning 200 with an error in the body — is the worst pattern in API design: it breaks HTTP-level monitoring (a 200 won't trigger an alerting rule), makes it impossible to detect errors without parsing every response body, and is the reason GraphQL's blanket use of HTTP 200 for all responses (including errors that carry a top-level errors array) is controversial — debugging a GraphQL API through a standard HTTP monitoring tool is blind to application-level failures.