Free HTTP Status Codes

A Standard with Three Decades of Drift

HTTP status codes have lived through several spec generations. RFC 1945 (May 1996) standardised HTTP/1.0 with the basic 1xx–5xx categories. RFC 2616 (June 1999) shipped HTTP/1.1 and was the canonical reference for over a decade. The 7230–7235 series (June 2014) split HTTP/1.1 into multiple specs by topic. The current consolidated standard is RFC 9110 "HTTP Semantics" (June 2022), which obsoletes the 7230–7235 split and is the right citation for modern work. The full live registry of assigned codes lives at IANA's HTTP status code registry.

The Five Categories at a Glance

• 1xx Informational: provisional response. The request was received and the server is continuing to process it. Rare in practice; useful for protocol upgrades and the modern 103 Early Hints (which lets servers preload critical resources before the full response is ready).
• 2xx Success: the request was received, understood, and accepted. 200 OK is the everyday case; 201 Created for resource creation; 204 No Content for successful actions with nothing to return.
• 3xx Redirection: further action needed. The classic redirects (301 Moved Permanently, 302 Found, 307 Temporary Redirect, 308 Permanent Redirect) plus 304 Not Modified for cache validation.
• 4xx Client Error: the client did something wrong: bad syntax, missing auth, requesting something that doesn't exist. The biggest category in real-world traffic.
• 5xx Server Error: the server messed up. The request was valid; the server just couldn't deliver. These are the ones that wake on-call engineers up.

The "vs" Comparisons That Trip Everyone Up

401 vs 403. The single most-confused pair. 401 Unauthorized means "you haven't authenticated, try logging in" (the name is technically misleading, it's about authentication, not authorization). 403 Forbidden means "you're authenticated, but you're not allowed to do this thing", your credentials are valid but they don't grant access to this resource. A common misuse: returning 403 for unauthenticated requests when 401 with a WWW-Authenticate header is correct.

301 vs 302 vs 307 vs 308. Two axes, permanent vs temporary, and method-preservation behaviour:

If you're redirecting GET requests for SEO purposes, 301 is the conventional choice. If you're redirecting POST or PUT requests and want the method preserved, you need 307 or 308.

400 vs 422. 400 Bad Request is for syntactically malformed requests, invalid JSON, missing required headers, malformed query parameters. 422 Unprocessable Entity (originally a WebDAV code, widely adopted by REST APIs) is for syntactically valid requests with semantic problems, the JSON parses correctly, but the values fail business validation (negative quantity on an order, email already in use). Many APIs use both.

502 vs 503 vs 504. Three different upstream-failure modes:

• 502 Bad Gateway: the proxy / gateway received an invalid response from the upstream server.
• 503 Service Unavailable: the server is overloaded or under maintenance. Often paired with a Retry-After header.
• 504 Gateway Timeout: the upstream server didn't respond in time.

404 vs 410. 404 Not Found is "we don't know if this exists or not." 410 Gone is "this used to exist, it's permanently removed." SEO impact: Google treats 410 as a stronger signal that content is permanently unavailable and removes it from the index faster than it does for 404.

REST API Conventions

Modern REST APIs converged on a fairly consistent set of conventions for what status codes mean for which actions:

SEO Implications

• 200 OK: Google indexes the page normally.
• 301 Moved Permanently: Google updates the indexed URL to the new one and transfers ranking signals.
• 302 Found / 307 Temporary Redirect: Google keeps the original URL indexed; ranking stays with the original.
• 308 Permanent Redirect: Google treats it like 301: ranking transfers.
• 304 Not Modified: used by Googlebot for conditional requests; signals that cached content can be reused.
• 404 Not Found: Google removes the URL from its index after a few crawls.
• 410 Gone: Google removes the URL faster than for 404; the stronger "permanently gone" signal.
• 503 Service Unavailable with Retry-After: tells Googlebot to come back later. Use during maintenance windows; avoid using 503 for genuine errors (Google interprets sustained 503s as instructions not to crawl).
• 5xx sustained: Google reduces crawl rate and may eventually drop the URL from the index entirely.

Famous & Cultural Codes

• 418 I'm a teapot: an April Fools' joke from RFC 2324 (Hyper Text Coffee Pot Control Protocol, 1 April 1998). When the IETF proposed dropping it from the spec in 2017, the "Save 418" campaign successfully kept it on the books. Some APIs use it as a "this isn't real" marker; otherwise harmless.
• 451 Unavailable For Legal Reasons: RFC 7725 (2015), named after Ray Bradbury's Fahrenheit 451. Returned when content is censored by court order or government request.
• Cloudflare's 520–527 series: non-standard, used by Cloudflare to indicate specific upstream-server connection failures. Common when a site behind Cloudflare has problems.
• Nginx's 444 No Response: Nginx-specific, returned when the server closes the connection without sending any response.
• Twitter's historical 420 Enhance Your Calm: a since-removed rate-limit code used by Twitter's earlier API; replaced by the standard 429.

Common Mistakes

1. Using 200 OK for errors with an error body. Returning {"error": "not found"} with a 200 status confuses every caching layer, monitoring tool, and client SDK. Use the right status code.
2. Returning 403 for unauthenticated requests. The right code is 401 with a WWW-Authenticate header.
3. Using 302 when you mean 301. If the move is permanent, search engines need the 301 to transfer ranking. 302 keeps the old URL indexed.
4. Using 301 or 302 for POST/PUT redirects. Historically these allowed clients to change the method to GET. 307 and 308 strictly preserve the original method.
5. Returning 500 when 503 is meant. If the server is overloaded or in maintenance, 503 with Retry-After is the correct signal, both for clients and for Googlebot.
6. Using 404 for permanently-removed pages. 410 Gone is the stronger signal and gets removed from search-engine indexes faster.
7. Forgetting the Location header on 201 and 3xx responses. The Location header is what tells the client where the new resource lives or where to redirect to. Without it, clients can't navigate.

More Frequently Asked Questions

When should I return 422 instead of 400?

400 Bad Request means the request itself is malformed, invalid JSON, missing required headers, malformed query parameters. 422 Unprocessable Entity means the request is well-formed but contains semantic errors that prevent processing, a quantity field set to a negative number, an email address that's already in use, a date in the past for a future-only field. Modern REST API conventions converged on this split, with most large APIs (GitHub, Stripe, Twilio) using 422 for validation errors.

Why does Cloudflare sometimes return 520, 521, 522…?

The 520–527 codes are Cloudflare-specific, signalling different ways their edge couldn't reach your origin server. 520 is the generic "web server returned an unknown error"; 521 means your origin refused the connection; 522 is a connection timeout to your origin; 524 means your origin took too long to respond. They're not in the IANA registry but are widely encountered when sites behind Cloudflare have backend issues.

Will my browser show me which code my API returned?

Yes, open DevTools → Network tab, click the request, and look at the "Status" column. Browsers also display generic pages for some codes (the dinosaur game on Chrome's connection failures, the standard 404 / 500 pages); but the actual numeric code is always in the response.

What is 103 Early Hints?

A relatively new (RFC 8297, 2017) 1xx code that lets the server send Link: rel=preload headers before the full response is ready, telling the browser to start fetching critical resources (CSS, fonts, images) early. Now supported by Chrome and shipped by Cloudflare, Fastly, and other CDNs as a performance optimisation.

Can I make up my own status code?

Technically yes (HTTP allows any 3-digit code in the 100–599 range. Practically no) clients, proxies, and caches treat unknown codes by their first digit (so 4xx = client error generically, 5xx = server error). Some vendors do this (Cloudflare's 520s, Nginx's 444), but unless you control both ends of the wire, stick to the IANA registry. Inventing a 299 won't break things but won't communicate anything either.

Why is the "status code" called a "status" and not an "error code"?

Because most of them aren't errors. 200 OK is the most-returned status code in the world, it means "everything went fine." The codes communicate the status of the request: success, redirect, client error, server error. Calling them "error codes" biases toward the negative cases that get logged and noticed; the success codes are doing their job silently every microsecond.