How to use this HTTP status code reference
Start with the search field when you remember a symptom (“gateway timeout”, “rate limit”) but not the exact number. Use the class filters (1xx–5xx) when you already know whether you are dealing with success, redirects, client mistakes, or upstream failures. Click Copy on any card to paste a structured explanation into tickets, runbooks, or Slack.
Import log accepts plain text from .txt, .log, or similar exports. We scan for three-digit codes in the 100–599 range and narrow the list to codes that appear in both your file and this reference—ideal after copying a slice of nginx, Apache, API gateway, or application logs. Clear the import anytime to return to the full table.
Guide: HTTP status classes at a glance
- 1xx informational — Interim responses; the client should wait for a final status. Common in upgrades, expect-continue flows, and early hints.
- 2xx success — The server accepted and processed the request. 200 OK is the default for successful GET; 201 Created and 204 No Content are frequent in REST APIs.
- 3xx redirection — Further action is needed, usually following a
Locationheader. 301/308 signal permanent moves; 302/307 are treated as temporary in most stacks. - 4xx client errors — The request was invalid, unauthorized, forbidden, not found, or rejected by policy (for example 400, 401, 403, 404, 429).
- 5xx server errors — The origin or an upstream failed after accepting the request (500, 502, 503, 504, and related codes).
SEO, redirects, and crawlers
Search engines use HTTP status codes together with headers and body content to decide whether to index a URL, follow a redirect, or drop a page from the index. Permanent redirects consolidate signals toward the target; soft or temporary behavior can leave duplicate URLs in play. When you audit a live URL, use our HTTP status code checker for the final status after redirects, the redirect chain checker for every hop, and the redirect type checker when you need to label 301 versus 302 behavior for SEO reporting.
APIs, JSON payloads, and documentation
REST and GraphQL gateways often return 4xx for caller mistakes and 5xx when dependencies fail—pair status codes with structured error bodies so clients can act. When you document APIs, align status codes with OpenAPI / Swagger definitions and validate payloads with the JSON formatter before publishing examples. For raw HTTP experiments, the HTTP request builder helps reproduce what you see in logs.
Headers, TLS, and “why doesn’t this match curl?”
Status codes describe the HTTP layer only. If you need Cache-Control, Set-Cookie, or security headers on the final response, use the HTTP header checker. For certificate issues that surface as TLS or handshake errors before a clean HTTP status is visible, validate the host with the SSL certificate checker.
Related tools in the API developer toolbox
Browse the full API developer toolbox section on the home page, or open a focused utility below.
- HTTP Request Builder — Test, document, and debug APIs without leaving the browser—pick method, headers, and body, then send with fetch.
- API Response Formatter — Paste any JSON or XML API response: pretty-print, validate, and explore a collapsible tree view.
- OpenAPI / Swagger Viewer — Paste OpenAPI in YAML or JSON and browse interactive docs—paths, schemas, and examples in one place.
- Webhook Payload Tester — Practice webhook debugging client-side: log sample POST bodies locally (e.g. localStorage) when a public capture URL is not available.
- MIME Type Lookup — Map filenames or extensions to MIME types for Content-Type headers, uploads, and API contracts.
- OAuth 2.0 Flow Visualizer — Walk through the authorization code flow step by step with interactive fields and diagrams.
- API Rate Limit Calculator — Given X requests per minute and a daily budget of Y calls, see pacing and when you hit the wall.