HTTP-Statuscodes: Vollständige Referenzanleitung

31. März 2026 · 12 Min. Lesezeit

Was sind HTTP-Statuscodes?

HTTP-Statuscodes sind dreistellige Zahlen, die von einem Server als Antwort auf die Anfrage eines Clients zurückgegeben werden. Sie zeigen an, ob die Anfrage erfolgreich war, umgeleitet wurde oder zu einem Fehler geführt hat. Jedes Mal, wenn Ihr Browser eine Seite lädt, eine API aufruft oder ein Formular absendet, antwortet der Server mit einem Statuscode.

Stellen Sie sich Statuscodes als die Art und Weise des Servers vor, zu kommunizieren, was mit Ihrer Anfrage passiert ist. Genau wie eine Ampel Ihnen sagt, ob Sie anhalten oder fahren sollen, teilen Statuscodes Ihrer Anwendung mit, ob sie fortfahren, es erneut versuchen oder einen Fehler behandeln soll.

Statuscodes werden basierend auf ihrer ersten Ziffer in fünf Kategorien gruppiert:

• 1xx (Informativ): Anfrage erhalten, Verarbeitung läuft weiter
• 2xx (Erfolg): Anfrage erhalten, verstanden und akzeptiert
• 3xx (Umleitung): Weitere Aktion erforderlich, um die Anfrage abzuschließen
• 4xx (Client-Fehler): Die Anfrage enthält einen Fehler auf der Client-Seite
• 5xx (Server-Fehler): Der Server konnte eine gültige Anfrage nicht erfüllen

Wie Statuscodes funktionieren

Wenn ein Client (wie Ihr Browser oder ein API-Client) eine HTTP-Anfrage stellt, verarbeitet der Server diese und gibt eine Antwort zurück. Diese Antwort enthält immer einen Statuscode in der ersten Zeile, gefolgt von Headern und einem optionalen Body.

So sieht eine typische HTTP-Antwort aus:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1234

{"status": "success", "data": {...}}

Der Statuscode erscheint direkt nach der HTTP-Version. In diesem Beispiel teilt 200 OK dem Client mit, dass die Anfrage erfolgreich war.

Statuscodes dienen mehreren Zwecken:

• Kommunikation: Sie bieten eine standardisierte Möglichkeit für Server, Ergebnisse zu kommunizieren
• Fehlerbehandlung: Anwendungen können verschiedene Szenarien basierend auf dem Code programmatisch behandeln
• Debugging: Entwickler können schnell erkennen, wo Probleme im Anfrage-Antwort-Zyklus auftreten
• SEO: Suchmaschinen verwenden Statuscodes, um zu verstehen, wie Inhalte indexiert werden sollen
• Caching: Browser und CDNs verwenden Codes, um das Caching-Verhalten zu bestimmen

1xx Informativ

Informative Statuscodes zeigen an, dass der Server die Anfrage erhalten hat und sie weiterhin verarbeitet. Dies sind vorläufige Antworten und werden beim alltäglichen Surfen im Web selten gesehen, aber sie sind wichtig für bestimmte Protokolle und Optimierungen.

100 Continue

Der Server hat die Anfrage-Header erhalten und der Client sollte mit dem Senden des Bodys fortfahren. Dies wird bei großen Uploads verwendet, bei denen der Client einen Expect: 100-continue-Header sendet, um zu prüfen, ob der Server die Anfrage akzeptiert, bevor die vollständige Nutzlast gesendet wird.

Diese Optimierung verhindert die Verschwendung von Bandbreite bei Anfragen, die abgelehnt werden. Wenn Sie beispielsweise eine 500-MB-Videodatei hochladen, möchten Sie nicht all diese Daten senden, nur um dann festzustellen, dass der Server sie aufgrund eines Authentifizierungsfehlers ablehnt.

POST /upload HTTP/1.1
Host: api.example.com
Content-Length: 524288000
Expect: 100-continue

// Server antwortet mit 100 Continue
// Client sendet dann den Anfrage-Body

101 Switching Protocols

Der Server stimmt zu, die Protokolle wie vom Client angefordert zu wechseln. Am häufigsten zu sehen beim Upgrade von HTTP zu WebSocket unter Verwendung des Upgrade: websocket-Headers.

WebSockets ermöglichen Echtzeit-Bidirektionale Kommunikation zwischen Client und Server, was für Chat-Anwendungen, Live-Updates und kollaborative Tools unerlässlich ist.

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade

// Server antwortet mit 101 Switching Protocols

103 Early Hints

Dieser relativ neue Statuscode ermöglicht es dem Server, vorläufige Header vor der endgültigen Antwort zu senden. Er wird häufig verwendet, um das Vorladen von Ressourcen wie CSS, Schriftarten und JavaScript-Dateien zu starten, während der Server noch die Hauptantwort vorbereitet.

Early Hints können die Seitenladezeiten erheblich verbessern, indem sie Browsern ermöglichen, kritische Ressourcen früher im Seitenladevorgang herunterzuladen.

2xx Erfolg

Erfolgscodes sind das, was Sie sehen möchten. Sie zeigen an, dass die Anfrage erfolgreich empfangen, verstanden und akzeptiert wurde. Verschiedene 2xx-Codes liefern nuancierte Informationen darüber, wie genau die Anfrage verarbeitet wurde.

200 OK

Die Standard-Erfolgsantwort. Die Anfrage war erfolgreich und der Antwort-Body enthält die angeforderten Daten. Dies ist der häufigste Statuscode im Web.

Verwenden Sie 200 OK für erfolgreiche GET-Anfragen, die Daten zurückgeben, erfolgreiche POST-Anfragen, die erstellte Ressourcendaten zurückgeben, und erfolgreiche PUT/PATCH-Anfragen, die aktualisierte Ressourcendaten zurückgeben.

GET /api/users/123 HTTP/1.1

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 123, "name": "John Doe", "email": "[email protected]"}

201 Created

Eine neue Ressource wurde erfolgreich erstellt. Dies ist die angemessene Antwort für POST-Anfragen, die neue Ressourcen erstellen. Die Antwort sollte einen Location-Header enthalten, der auf die neu erstellte Ressource verweist.

POST /api/users HTTP/1.1
Content-Type: application/json

{"name": "Jane Smith", "email": "[email protected]"}

HTTP/1.1 201 Created
Location: /api/users/124
Content-Type: application/json

{"id": 124, "name": "Jane Smith", "email": "[email protected]"}

202 Accepted

Die Anfrage wurde zur Verarbeitung akzeptiert, aber die Verarbeitung wurde noch nicht abgeschlossen. Dies ist nützlich für asynchrone Operationen, bei denen der Server die Anfrage zur späteren Verarbeitung in die Warteschlange stellt.

Häufige Anwendungsfälle sind Stapelverarbeitung, E-Mail-Versand, Video-Codierung und andere langwierige Operationen, die die HTTP-Antwort nicht blockieren sollten.

204 No Content

Die Anfrage war erfolgreich, aber es gibt keinen Inhalt zurückzugeben. Dies wird häufig für DELETE-Anfragen oder PUT/PATCH-Anfragen verwendet, bei denen der Client die aktualisierte Ressource nicht zurückgegeben benötigt.

Die Verwendung von 204 No Content anstelle von 200 OK mit einem leeren Body spart Bandbreite und kommuniziert die Absicht klar.

DELETE /api/users/123 HTTP/1.1

HTTP/1.1 204 No Content

206 Partial Content

Der Server liefert nur einen Teil der Ressource aufgrund eines vom Client gesendeten Range-Headers. Dies ermöglicht fortsetzbare Downloads und Video-Streaming, bei denen der Client bestimmte Byte-Bereiche anfordert.

Videoplayer verwenden dies ausgiebig, um das Springen zu verschiedenen Teilen eines Videos zu ermöglichen, ohne zuerst die gesamte Datei herunterladen zu müssen.

3xx Umleitung

Umleitungscodes zeigen an, dass der Client zusätzliche Maßnahmen ergreifen muss, um die Anfrage abzuschließen. Diese sind entscheidend für URL-Verwaltung, SEO und die Aufrechterhaltung der Abwärtskompatibilität, wenn Ressourcen verschoben werden.

301 Moved Permanently

Die Ressource wurde dauerhaft zu einer neuen URL verschoben, die im Location-Header angegeben ist. Browser und Suchmaschinen sollten ihre Aufzeichnungen aktualisieren, um die neue URL zu verwenden.

Dies ist der bevorzugte Statuscode für permanente Umleitungen. Suchmaschinen übertragen den SEO-Wert von der alten URL auf die neue, und Browser cachen die Umleitung.

GET /old-page HTTP/1.1

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

302 Found (Temporäre Umleitung)

Die Ressource befindet sich vorübergehend unter einer anderen URL. Der Client sollte weiterhin die ursprüngliche URL für zukünftige Anfragen verwenden. Suchmaschinen übertragen mit dieser Umleitung keinen SEO-Wert.

Häufige Anwendungsfälle sind A/B-Tests, Wartungsseiten und temporäre Werbeseiten.

303 See Other

Die Antwort auf die Anfrage kann unter einer anderen URL mit GET gefunden werden. Dies wird häufig nach POST-Anfragen verwendet, um zu einer Ergebnisseite umzuleiten und doppelte Formularübermittlungen zu verhindern, wenn der Benutzer aktualisiert.

Dies implementiert das Post/Redirect/Get-Muster, das eine Best Practice für Webformulare ist.

304 Not Modified

Die Ressource wurde seit der in den Anfrage-Headern angegebenen Version (If-Modified-Since oder If-None-Match) nicht geändert. Der Client kann seine zwischengespeicherte Version verwenden.

Dies reduziert die Bandbreitennutzung dramatisch und verbessert die Leistung, indem unnötige Datenübertragungen vermieden werden, wenn sich der Inhalt nicht geändert hat.

307 Temporary Redirect

Ähnlich wie 302, garantiert aber, dass sich die Anfragemethode bei der Umleitung nicht ändert. Wenn die ursprüngliche Anfrage POST war, wird die umgeleitete Anfrage ebenfalls POST sein.

308 Permanent Redirect

Ähnlich wie 301, garantiert aber, dass sich die Anfragemethode nicht ändert. Dies ist die moderne, präzisere Version von 301 für APIs und Anwendungen, die eine strikte Methodenbeibehaltung benötigen.

4xx Client-Fehler

Client-Fehlercodes zeigen an, dass die Anfrage fehlerhafte Syntax enthält oder aufgrund von clientseitigen Problemen nicht erfüllt werden kann. Diese Fehler bedeuten, dass der Client die Anfrage ändern muss, bevor er es erneut versucht.

400 Bad Request

Der Server kann die Anfrage aufgrund fehlerhafter Syntax, ungültiger Anfragenachrichtenrahmung oder irreführender Anfragerouting nicht verarbeiten. Dies ist ein allgemeiner Fehler für Anfragen, die nicht in andere 4xx-Kategorien passen.

Häufige Ursachen sind fehlerhaftes JSON, fehlende erforderliche Felder, ungültige Datentypen oder Anfragen, die API-Einschränkungen verletzen.

POST /api/users HTTP/1.1
Content-Type: application/json

{"name": "John", "email": "not-an-email"}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error": "Invalid email format"}

401 Unauthorized

Authentifizierung ist erforderlich und ist fehlgeschlagen oder wurde nicht bereitgestellt. Trotz des Namens bedeutet dies tatsächlich "nicht authentifiziert" – der Client muss gültige Anmeldeinformationen bereitstellen.

Die Antwort sollte einen WWW-Authenticate-Header enthalten, der die erforderliche Authentifizierungsmethode angibt.

GET /api/protected-resource HTTP/1.1

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api"

{"error": "Authentication required"}

403 Forbidden

Der Server hat die Anfrage verstanden, weigert sich aber, sie zu autorisieren. Im Gegensatz zu 401 hilft Authentifizierung nicht – der Client hat keine Berechtigung, auf diese Ressource zuzugreifen.

Verwenden Sie dies, wenn ein Benutzer authentifiziert ist, aber nicht über die erforderlichen Berechtigungen verfügt, oder wenn der Zugriff durch IP-Adresse, Ratenbegrenzung oder andere Richtlinien eingeschränkt ist.