Wie benutzt du dieses Tool?
- Suchfeld nutzen — Code-Nummer, Reason-Phrase oder Stichwort. Beispiel: 404, „not found", „bad gateway".
- Klassen-Tabs (1xx-5xx) filtern auf eine Code-Familie. RFC- oder Plattform-Toggle blendet eine der beiden Welten aus.
- Code-Karte links anklicken — Details rechts erscheinen mit RFC- und Wikipedia-Link plus typischen HTTP-Methoden.
- Bei Verwechslungs-Codes (401 vs 403, 301/302/307/308, 400 vs 422, 502/503/504) erscheint eine Vergleichs-Karte mit Klick-Through zu den Peer-Codes.
- Snippet-Block unten emittiert die komplette Liste als TypeScript-Enum, Python-Dict, Go-const, Rust-Enum, Java-Record oder Ruby-Module. Copy oder Download.
Was macht das HTTP-Status-Codes-Tool?
Das Tool ist ein durchsuchbarer Referenz-Catalog für HTTP-Status-Codes. Es deckt RFC 9110 vollständig ab — alle 1xx-Informational-, 2xx-Success-, 3xx-Redirection-, 4xx-Client-Error- und 5xx-Server-Error- Codes — und ergänzt um die Plattform-spezifischen Codes, die in der RFC-Registry fehlen, im Production- Log aber täglich auftauchen: Cloudflare 520-530, nginx 444 und 494-499, IIS 440 und 449, AWS Application Load Balancer 460/463 und CloudFront 561.
Pro Code zeigt das Tool: die kanonische Reason-Phrase, eine technische Erklärung in zwei bis vier Sätzen, die typischen HTTP-Methoden (POST liefert tendenziell 201, GET tendenziell 200), den Link zur Spezifikation (RFC, Cloudflare-Docs, nginx-Source) und einen Link zur Wikipedia-Übersicht für editorialen Kontext.
Welche Plattform-Codes deckt das Tool ab?
MDN dokumentiert nur den IANA-registrierten Standard. Tools, die im Production-Stack vorkommen, emittieren aber regelmäßig nicht-standardisierte Codes:
- Cloudflare 520-527 und 530 — die komplette „Edge konnte den Origin nicht erreichen”-Familie. 521 (Origin offline), 522 (Connection-Timeout), 523 (Origin-DNS-Fehler), 524 (Origin-Antwort > 100 s), 525 und 526 (Origin-SSL-Probleme), 527 (Railgun-Fehler), 530 (Wrapper für 1xxx-Fehler).
- nginx 444 und 494-499 — interne Codes aus der nginx-Source: 444 (Connection still gedroppt), 494 (Header zu groß), 495 und 496 (Client-Cert-Probleme), 497 (HTTP-auf-HTTPS-Port), 499 (Client hat Verbindung geschlossen).
- IIS 440 und 449 — Microsoft-spezifische Codes: 440 (Login-Timeout), 449 (Retry-With).
- AWS Application Load Balancer 460/463 und CloudFront 561 — Cloud-Provider-Edge-Codes für Client-Timeout, übergroße X-Forwarded-For-Chain, Lambda@Edge-Auth-Fail.
Der Filter „Nur Plattform-Codes” blendet den RFC-Standard aus und zeigt nur diese Welt — nützlich, wenn du nach einem konkreten 5xx-Vorfall im Cloudflare-Dashboard nachschlägst.
Was sind Verwechslungs-Cards?
Vier Code-Paare werden 2026 am häufigsten verwechselt — das Tool blendet automatisch eine Vergleichs-Karte ein, sobald du einen der Codes auswählst:
- 401 vs 403 — Authentifizierung (kein Login) vs Autorisierung (Login da, aber kein Recht).
- 301 vs 302 vs 307 vs 308 — Permanenz × Methoden-Erhalt als Wahrheits-Tabelle. 308 = permanent + method-preserving, die moderne Wahl.
- 400 vs 422 — HTTP-Layer-Fehler (Syntax, Framing) vs Geschäftsregel-Fehler (Validierung, Conflict). 422 nutzen, wenn das JSON syntaktisch ok ist aber das E-Mail-Feld ungültig.
- 502 vs 503 vs 504 — Upstream defekt vs Origin überlastet vs Upstream stumm. Die drei Gateway-Fehler sehen ähnlich aus, haben aber unterschiedliche Root-Cause-Diagnosen.
Pro Cluster gibt es eine ein-bis-zwei-Satz-Zusammenfassung und Buttons zu den Peer-Codes — Click-Through ohne URL-Wechsel.
Wie funktioniert der HTTP-Methoden-Filter?
Jeder Code in der Datenbank trägt eine Liste „typische HTTP-Methoden, die diesen Code erzeugen”. Der Filter „HTTP-Methode” blendet die Liste auf eine Methode ein: Klick „POST” zeigt nur Codes, die nach einem POST sinnvoll sind — 200, 201, 202, 204, 303, 307, 400, 409, 422, 429, 500. Klick „GET” zeigt die GET-typischen Codes — 200, 206, 301, 304, 404, 410.
Das ist die inverse Sicht zur Detail-Karte: Dort sagt jeder Code „diese Methoden lösen mich aus”, der Filter sagt „diese Methode liefert mir folgende Codes”.
Welche Snippet-Sprachen unterstützt der Export?
Sechs Zielsprachen, alle pure-client generiert:
- TypeScript-Enum —
export enum HttpStatus { NOT_FOUND = 404, … }mit JSDoc-Kommentaren. - Python-Dict —
HTTP_STATUS_CODES = { 404: "Not Found", … }als Lookup-Map. - Go-Const-Block —
const ( StatusNot_Found = 404 … )im idiomatic Go-Style. - Rust-Enum —
#[repr(u16)] pub enum HttpStatus { Not_Found = 404, … }mit u16-Repräsentation. - Java-Record —
public record HttpStatus(int code, String name)plus statische Final-Constants. - Ruby-Module —
module HttpStatus NOT_FOUND = 404 … endals Konstanten-Container.
Per Default emittiert der Export alle Codes — Standard plus Plattform-Codes. Du kannst die Auswahl per „Nur RFC-Standard”-Toggle einschränken, dann erscheint die Plattform-Welt nicht im generierten Code. Beide Snippets sind sauber kommentiert und können direkt in einen Codebase eingefügt werden — keine Tests, keine Abhängigkeiten, keine Compiler-Warnungen erwartet.
Warum läuft die Suche pure-client ohne Tracking?
Dieses Tool sendet keinen Request an einen Server. Die komplette Status-Code-Datenbank ist im JavaScript-
Bundle eingebettet, die Suche läuft per String.prototype.toLowerCase und includes, die Snippet-
Generierung per Template-String. Keine API-Calls, keine Telemetrie, keine Cookies, kein localStorage.
Mehr im OWASP Logging Cheat Sheet zur Frage, was eine Tool-Suche eigentlich preisgibt — und warum es bei sicherheits-relevanten Lookups (Status-Code-Recherche während eines Incidents) wichtig ist, dass die Suche nicht in einem fremden Log landet. Die IANA HTTP Status Code Registry ist die kanonische Quelle für IANA-registrierte Codes; alles darüber hinaus stammt direkt aus den Plattform-Dokumentationen (Cloudflare 5xx-Errors, nginx HTTP request processing, Microsoft IIS HTTP status codes).
Zuletzt aktualisiert: