100
Continue
Der Server hat die Request-Header erhalten und der Client kann mit dem Body fortfahren. Verhindert das Senden großer Payloads, wenn der Server die Anfrage ablehnen könnte.
Alle Utilities
Referenz
HTTP-Statuscodes
Durchsuchbares Nachschlagewerk gängiger HTTP-Antwortcodes.
1xx Informativ
101
Switching Protocols
Der Server stimmt dem Protokollwechsel zu (z. B. von HTTP zu WebSocket), wie im Upgrade-Header angefordert.
102
Processing
Der Server hat die Anfrage erhalten und verarbeitet sie, aber es ist noch kein Response-Body verfügbar. Wird bei lang laufenden Operationen verwendet.
2xx Erfolg
200
OK
Die Anfrage war erfolgreich. Der Response-Body enthält typischerweise die angeforderte Ressource oder das Ergebnis der Operation.
201
Created
Die Anfrage war erfolgreich und eine neue Ressource wurde erstellt. Oft nach POST mit Location-Header, der auf die neue Ressource verweist.
202
Accepted
Die Anfrage wurde zur Verarbeitung angenommen, ist aber noch nicht abgeschlossen. Häufig bei asynchronen Jobs und Hintergrundaufgaben.
204
No Content
Die Anfrage war erfolgreich, aber es gibt keinen Inhalt zurückzugeben. Typisch für erfolgreiche DELETE- oder PUT-Updates mit leerem Body.
3xx Weiterleitung
301
Moved Permanently
Die Ressource wurde dauerhaft auf eine neue URL verschoben. Clients und Suchmaschinen sollten Lesezeichen und Links aktualisieren.
302
Found
Die Ressource ist vorübergehend unter einer anderen URL verfügbar. Künftige Anfragen können weiterhin die ursprüngliche URL nutzen.
303
See Other
Nach einem POST sollte der Client das Ergebnis per GET unter der URL aus dem Location-Header abrufen.
304
Not Modified
Die gecachte Version ist noch gültig. Der Server liefert keinen Body; der Client sollte seinen lokalen Cache nutzen.
307
Temporary Redirect
Temporäre Weiterleitung, die die ursprüngliche HTTP-Methode beibehält. Im Gegensatz zum alten 302-Verhalten bleibt POST nach Redirect POST.
308
Permanent Redirect
Permanente Weiterleitung, die die ursprüngliche HTTP-Methode beibehält. Der Client sollte die neue URL für künftige Anfragen verwenden.
4xx Client-Fehler
400
Bad Request
Der Server kann die Anfrage wegen ungültiger Syntax, fehlender Felder oder fehlerhaftem JSON nicht verarbeiten. Anfrage korrigieren und erneut versuchen.
401
Unauthorized
Authentifizierung ist erforderlich oder fehlgeschlagen. Der Client sollte gültige Anmeldedaten bereitstellen, oft über den Authorization-Header oder Login.
403
Forbidden
Der Server hat die Anfrage verstanden, lehnt die Autorisierung aber ab. Der Benutzer ist möglicherweise authentifiziert, hat aber keine Berechtigung.
404
Not Found
Die angeforderte URL oder Ressource existiert nicht. Pfad, Route oder ID prüfen — oder das Element wurde entfernt.
405
Method Not Allowed
Die HTTP-Methode ist für diesen Endpoint nicht erlaubt. Beispielsweise POST senden, wo nur GET unterstützt wird.
408
Request Timeout
Der Server hat beim Warten auf die vollständige Anfrage ein Timeout. Oft durch langsame Uploads oder inaktive Verbindungen verursacht.
409
Conflict
Die Anfrage steht im Konflikt mit dem aktuellen Ressourcenzustand. Häufig bei Duplikaten oder Verletzung von Versionsbeschränkungen.
410
Gone
Die Ressource existierte, wurde aber dauerhaft entfernt und ist nicht mehr verfügbar. Stärker als 404 für gelöschte Inhalte.
413
Payload Too Large
Der Request-Body ist größer als der Server verarbeiten möchte. Payload-Größe reduzieren oder Chunked Upload nutzen.
414
URI Too Long
Die Anfrage-URL überschreitet das Server-Limit. Query-Strings kürzen oder Daten in den Request-Body verschieben.
415
Unsupported Media Type
Der Server unterstützt den Request-Content-Type nicht. JSON, Formulardaten oder ein anderes vom API akzeptiertes Format senden.
418
I'm a teapot
In RFC 2324 als April Fools'-Scherz definiert: Der Server weigert sich, Kaffee zu kochen, weil er eine Teekanne ist. Wird manchmal in Demos verwendet.
422
Unprocessable Entity
Die Anfrage ist syntaktisch gültig, aber semantisch falsch. Typisch für Validierungsfehler in REST-APIs und Webformularen.
429
Too Many Requests
Der Client hat zu viele Anfragen in einem Zeitfenster gesendet. Retry-After beachten und Backoff oder Rate Limiting implementieren.
5xx Server-Fehler
500
Internal Server Error
Ein unerwarteter Fehler ist auf dem Server aufgetreten. In der Regel nicht die Schuld des Clients — Server-Logs prüfen und später erneut versuchen.
501
Not Implemented
Der Server unterstützt die zur Erfüllung der Anfrage erforderliche Funktionalität nicht. Die Methode oder Funktion ist nicht implementiert.
502
Bad Gateway
Ein Gateway oder Proxy hat eine ungültige Antwort von einem Upstream-Server erhalten. Häufig hinter Load Balancern, wenn Backends ausfallen.
503
Service Unavailable
Der Server ist vorübergehend nicht verfügbar, oft wegen Wartung oder Überlastung. Nach Verzögerung erneut versuchen; Retry-After prüfen, falls vorhanden.
504
Gateway Timeout
Ein Gateway oder Proxy hat keine rechtzeitige Antwort vom Upstream-Server erhalten. Deutet auf langsame Backends oder Netzwerkprobleme hin.
32 gängige HTTP-Statuscodes
Über dieses Tool
Nachschlagen, was 301, 403, 429 und andere Codes beim Debugging bedeuten.
Durchsuchbares Nachschlagewerk gängiger HTTP-Antwortcodes.
Häufig gestellte Fragen
- Ist HTTP-Statuscodes kostenlos?
- Ja. Alle Cleariflow-Utilities sind ohne Registrierung nutzbar. Für Automatisierung und höhere Limits empfehlen wir die passende Production-API.
- Wer nutzt HTTP-Statuscodes im Alltag?
- Entwickler, DevOps, Support und Marketing-Teams — für schnelle Checks vor tieferer Analyse, Incidents oder Integrationstests.
- Wann sollte ich zur API wechseln?
- HTTP-Statuscodes eignet sich für manuelle und Ad-hoc-Prüfungen. Für Batch-Jobs, Webhooks oder SLA-gestützte Workflows integrieren Sie die Cleariflow-API.