HTTP Status Codes — Cloudflare, nginx, Snippets

What does the HTTP status codes tool do?

The tool is a searchable reference catalogue for HTTP status codes. It covers RFC 9110 completely — every 1xx informational, 2xx success, 3xx redirection, 4xx client-error and 5xx server-error code — and adds the platform-specific codes that the IANA registry omits but that appear in your production log every day: Cloudflare 520-530, nginx 444 and 494-499, IIS 440 and 449, AWS Application Load Balancer 460/463, and CloudFront 561.

For each code the tool shows: the canonical reason phrase, a technical explanation in two to four sentences, the typical HTTP methods (POST tends to return 201, GET tends to return 200), a link to the specification (RFC, Cloudflare docs, nginx source), and a Wikipedia link for editorial context.

Which platform codes does the tool cover?

MDN documents only the IANA-registered standard. Tools that ship in your production stack regularly emit non-standard codes:

• Cloudflare 520-527 and 530 — the full ‘edge could not reach the origin’ family. 521 (origin offline), 522 (connection timeout), 523 (origin DNS error), 524 (origin response > 100 s), 525 and 526 (origin SSL issues), 527 (Railgun error), 530 (wrapper for the 1xxx error series).
• nginx 444 and 494-499 — internal codes from the nginx source: 444 (connection silently dropped), 494 (request header too large), 495 and 496 (client-certificate problems), 497 (HTTP request on HTTPS port), 499 (client closed the connection).
• IIS 440 and 449 — Microsoft-specific codes: 440 (login timeout), 449 (Retry With).
• AWS Application Load Balancer 460/463 and CloudFront 561 — cloud-provider edge codes for client timeout, oversized X-Forwarded-For chain, and Lambda@Edge auth failure.

The ‘platform codes only’ filter hides the RFC standard and shows only this world — useful when you look up a specific 5xx incident in the Cloudflare dashboard.

What are confusion cards?

Four code pairs are the most-confused in 2026 — the tool auto-shows a comparison card as soon as you select one of the codes:

• 401 vs 403 — authentication (no login) vs authorisation (logged in but no permission).
• 301 vs 302 vs 307 vs 308 — permanence × method preservation as a truth table. 308 = permanent + method preserving, the modern default.
• 400 vs 422 — HTTP-layer error (syntax, framing) vs business-rule error (validation, conflict). Use 422 when the JSON is syntactically fine but the email field is invalid.
• 502 vs 503 vs 504 — upstream broken vs origin overloaded vs upstream silent. The three gateway errors look similar but have different root-cause diagnoses.

Each cluster carries a one-to-two-sentence summary and buttons to the peer codes — click-through with no URL change.

How does the HTTP method filter work?

Every code in the database carries a list of ‘typical HTTP methods that produce this code’. The HTTP method filter narrows the list to one method: click ‘POST’ and you see only codes that make sense after a POST — 200, 201, 202, 204, 303, 307, 400, 409, 422, 429, 500. Click ‘GET’ and you see the GET-typical codes — 200, 206, 301, 304, 404, 410.

That is the inverse view of the detail card: there, each code says ‘these methods trigger me’; the filter says ‘this method returns me the following codes’.

Which snippet languages does the exporter support?

Six target languages, all generated client-side:

• TypeScript enum — export enum HttpStatus { NOT_FOUND = 404, … } with JSDoc comments.
• Python dict — HTTP_STATUS_CODES = { 404: "Not Found", … } as a lookup map.
• Go const block — const ( StatusNot_Found = 404 … ) in idiomatic Go style.
• Rust enum — #[repr(u16)] pub enum HttpStatus { Not_Found = 404, … } with u16 representation.
• Java record — public record HttpStatus(int code, String name) plus static final constants.
• Ruby module — module HttpStatus NOT_FOUND = 404 … end as a constants container.

By default the exporter emits all codes — standard plus platform codes. You can narrow the selection with the ‘RFC standard only’ toggle; the platform world then disappears from the generated code. Both snippets are cleanly commented and can drop into a codebase as-is — no tests, no dependencies, no compiler warnings expected.

Why does this run pure-client without tracking?

This tool sends no request to a server. The whole status code database is embedded in the JavaScript bundle, search runs via String.prototype.toLowerCase and includes, snippet generation runs via template strings. No API calls, no telemetry, no cookies, no localStorage.

More in the OWASP Logging Cheat Sheet on what a tool search actually exposes — and why for security-relevant lookups (status-code research during an incident) it matters that the search does not end up in someone else’s log. The IANA HTTP Status Code Registry is the canonical source for IANA-registered codes; everything beyond that comes directly from platform documentation (Cloudflare 5xx errors, nginx HTTP request processing, Microsoft IIS HTTP status codes).