
Geräteinformationen
Infos zu Ihrem Gerät: Betriebssystem, Browser und mehr.
Referenz für HTTP-Statuscodes: Bedeutung, Beispiele und Best Practices.
Stand: IANA-Register vom 15. September 2025. Aufgeführt sind registrierte Codes; nicht zugewiesene Nummernbereiche fehlen bewusst. Kurzbezeichnungen sind Empfehlungen und können in Antworten entfallen.
Der Server hat den Anfang der Anfrage erhalten und der Client soll mit dem Senden des Anfragekörpers fortfahren.
Der Server akzeptiert den vom Client angeforderten Protokollwechsel.
Der Server verarbeitet die Anfrage, es liegt aber noch keine Antwort vor (WebDAV).
Der Server sendet vorab einige Antwort-Header, bevor die endgültige HTTP-Nachricht folgt.
Temporär registrierter Hinweis für wiederaufnehmbare Uploads; die aktuelle IANA-Registrierung läuft am 13. November 2026 aus.
Standardantwort für erfolgreiche HTTP-Anfragen.
Die Anfrage war erfolgreich und führte zur Erstellung einer neuen Ressource.
Die Anfrage wurde zur Verarbeitung angenommen, ist aber noch nicht abgeschlossen.
Der Server liefert eine modifizierte Version der ursprünglich vom Origin-Server empfangenen 200-Antwort.
Die Anfrage wurde erfolgreich verarbeitet, die Antwort enthält aber keinen Inhalt.
Wie 204, zusätzlich soll der Client das anfragende Formular zurücksetzen.
Der Server liefert aufgrund eines Range-Headers nur einen Teil der angeforderten Ressource.
Der Antwortkörper enthält eine XML-Nachricht mit mehreren unabhängigen Statuscodes (WebDAV).
Vermeidet die wiederholte Aufzählung interner Mitglieder mehrerer Bindungen in einem DAV-propstat-Element.
Die Antwort ist das Ergebnis einer oder mehrerer Instanzmanipulationen, die auf die aktuelle Instanz angewendet wurden.
Für die Anfrage gibt es mehrere mögliche Antworten; der Client soll eine davon auswählen.
Die angeforderte Ressource wurde dauerhaft unter eine neue URL verschoben.
Die Ressource befindet sich vorübergehend unter einer anderen URL.
Die Antwort ist unter einer anderen URI mittels GET-Methode zu finden.
Die Ressource wurde seit der letzten Anfrage nicht verändert; der Client kann die zwischengespeicherte Version nutzen.
Historischer Proxy-Hinweis. RFC 9110 rät aus Sicherheitsgründen davon ab, diesen Code zu erzeugen.
Der Code ist unbenutzt; die frühere Bedeutung aus einer älteren HTTP-Spezifikation gilt nicht mehr.
Die Ressource befindet sich vorübergehend unter einer anderen URI, die Methode bleibt dabei unverändert.
Die Ressource befindet sich dauerhaft unter einer anderen URI, die Methode bleibt dabei unverändert.
Der Server kann die Anfrage aufgrund fehlerhafter Syntax nicht verarbeiten.
Authentifizierung ist erforderlich, fehlt aber oder ist fehlgeschlagen.
Für zukünftige Verwendung reserviert, ursprünglich für digitale Bezahlsysteme vorgesehen.
Der Client hat keine Zugriffsberechtigung auf den angeforderten Inhalt.
Der Server kann die angeforderte Ressource nicht finden.
Die verwendete Anfragemethode wird von der Zielressource nicht unterstützt.
Der Server kann keine Antwort erzeugen, die den im Accept-Header geforderten Kriterien entspricht.
Der Client muss sich zuerst gegenüber dem Proxy authentifizieren.
Der Server hat beim Warten auf die vollständige Anfrage die Zeitgrenze überschritten.
Die Anfrage steht im Konflikt mit dem aktuellen Zustand der Ressource.
Die Ressource wurde absichtlich und dauerhaft entfernt und ist nicht mehr verfügbar.
Die Anfrage hat den erforderlichen Content-Length-Header nicht angegeben.
Eine vom Client gesetzte Vorbedingung wird vom Server nicht erfüllt.
Der Anfrageinhalt ist größer, als der Server bereit oder in der Lage ist zu verarbeiten.
Der angegebene URI ist zu lang, um vom Server verarbeitet zu werden.
Der Medientyp der Anfrage wird vom Server oder der Ressource nicht unterstützt.
Der angeforderte Teilbereich der Datei kann vom Server nicht bereitgestellt werden.
Der Server kann die im Expect-Header geforderten Bedingungen nicht erfüllen.
RFC 9110 reserviert den bekannten „Teapot“-Code als unbenutzt; er hat keine allgemeine HTTP-Semantik.
Die Anfrage wurde an einen Server geleitet, der keine passende Antwort erzeugen kann.
Der Inhaltstyp und die Syntax werden verstanden, die enthaltenen Anweisungen konnten aber nicht verarbeitet werden.
Die angeforderte Ressource ist gesperrt.
Die Anfrage ist fehlgeschlagen, weil eine vorherige, abhängige Anfrage fehlgeschlagen ist.
Der Server verarbeitet die Anfrage nicht, um das Risiko einer Replay-Attacke zu vermeiden.
Der Client soll auf ein anderes, im Upgrade-Header angegebenes Protokoll wechseln.
Der Origin-Server verlangt, dass die Anfrage bedingt gestellt wird.
Der Client hat in kurzer Zeit zu viele Anfragen gesendet (Rate-Limiting).
Einzelne oder alle Header-Felder der Anfrage sind zu groß für den Server.
Der Zugriff auf die Ressource ist aus rechtlichen Gründen gesperrt, etwa durch behördliche Anordnung.
Der Server ist auf eine unerwartete Situation gestoßen, die er nicht genauer beschreiben kann.
Der Server unterstützt die angeforderte Methode nicht und kann sie nicht verarbeiten.
Der Server hat als Gateway oder Proxy eine ungültige Antwort vom vorgelagerten Server erhalten.
Der Server ist derzeit nicht in der Lage, die Anfrage zu bearbeiten, oft wegen Wartung oder Überlastung.
Der Server hat als Gateway oder Proxy keine rechtzeitige Antwort vom vorgelagerten Server erhalten.
Die in der Anfrage verwendete HTTP-Version wird vom Server nicht unterstützt.
Interner Konfigurationsfehler: Die Inhaltsverhandlung für die Anfrage führt zu einer Endlosreferenz.
Der Server kann die zur Erfüllung der Anfrage nötige Darstellung nicht speichern.
Der Server hat bei der Verarbeitung der Anfrage eine Endlosschleife erkannt.
Historischer Erweiterungs-Code, dessen Registrierung inzwischen als obsolet gekennzeichnet ist.
Der Client muss sich authentifizieren, um Zugang zum Netzwerk zu erhalten.
Statuscodes sind in fünf Gruppen unterteilt: 1xx Information, 2xx Erfolg, 3xx Umleitung, 4xx Client-Fehler und 5xx Server-Fehler.
IANA führt die registrierten Codes und ihre Spezifikationen. Die zentralen HTTP-Semantiken stehen heute in RFC 9110, der RFC 7231 ersetzt hat.
Codes wie 301, 404 und 410 beeinflussen, wie Suchmaschinen URLs behandeln – wichtig für Weiterleitungen und die Indexierung.
Clients müssen nicht jeden registrierten Code kennen. RFC 9110 verlangt aber, dass sie die Klasse an der ersten Ziffer erkennen und unbekannte Codes entsprechend behandeln.
HTTP-Statuscodes sind dreistellige Zahlen im Bereich 100 bis 599, die zu den Kontrolldaten einer HTTP-Antwort gehören. Sie zeigen an, ob eine Anfrage erfolgreich war, ob eine Umleitung nötig ist, ob der Client einen Fehler gemacht hat oder ob auf dem Server ein Problem aufgetreten ist. Die erste Ziffer bestimmt die Kategorie der Antwort.
Für Entwickler und Betreiber von APIs sind Statuscodes essenziell für Debugging, Monitoring und korrektes Fehlerhandling im Frontend. Suchmaschinen nutzen bestimmte Codes (z. B. 301, 404, 410), um Umleitungen und entfernte Inhalte im Index korrekt zu behandeln.
Ein HTTP-Statuscode ist eine dreistellige Zahl, die ein Server als Teil jeder HTTP-Antwort sendet. Sie gibt an, ob eine Anfrage erfolgreich war, umgeleitet wurde oder ein Fehler aufgetreten ist.
Die erste Ziffer legt die Kategorie fest: 1 = Information, 2 = Erfolg, 3 = Umleitung, 4 = Client-Fehler, 5 = Server-Fehler.
404 (Not Found) sagt, dass keine aktuelle Darstellung gefunden wurde oder der Server ihre Existenz nicht offenlegen will. 410 (Gone) ist die deutlichere Aussage, dass der Zugriff voraussichtlich dauerhaft nicht mehr möglich ist.
301 (Moved Permanently) bezeichnet eine dauerhafte, 302 (Found) eine vorübergehende Ziel-URI. Wenn die HTTP-Methode bei der Weiterleitung sicher unverändert bleiben muss, sind 308 beziehungsweise 307 die eindeutigeren Varianten.
500 (Internal Server Error) bedeutet, dass der Server auf eine unerwartete Bedingung gestoßen ist und die Anfrage deshalb nicht erfüllen konnte. Der Code allein verrät die technische Ursache nicht; dafür sind Serverprotokolle nötig.
Grundlagen, Spezifikationen und weiterführende Angaben zu diesem Werkzeug:
Quellen geprüft am 28. August 2026.