HTTP Status Code Reference — Complete Guide to HTTP Response Codes
Understanding the Basics
HTTP status codes are three-digit numeric codes returned by web servers in response to client requests, indicating the outcome of the request. Defined in RFC 9110 (the current HTTP/1.1 semantics standard, which superseded RFC 7231), they are grouped into five classes by their first digit: 1xx (Informational — request received, processing continues), 2xx (Successful — request received, understood, and accepted), 3xx (Redirection — further action required by client), 4xx (Client Error — request contains bad syntax or cannot be fulfilled), and 5xx (Server Error — server failed to fulfill valid request). The most commonly encountered codes are: 200 OK (success), 201 Created (resource created), 204 No Content (success with no body), 301 Moved Permanently (redirect), 302 Found (temporary redirect), 304 Not Modified (cached response still valid), 400 Bad Request (malformed request), 401 Unauthorized (authentication required), 403 Forbidden (authenticated but lacking permission), 404 Not Found (resource doesn't exist), 405 Method Not Allowed, 409 Conflict (duplicate resource), 422 Unprocessable Entity (validation failure), 429 Too Many Requests (rate limited), 500 Internal Server Error, 502 Bad Gateway (upstream error), 503 Service Unavailable (overloaded), and 504 Gateway Timeout. Understanding HTTP status codes is fundamental to debugging API integrations, designing REST APIs, configuring CDNs and load balancers, and building HTTP client retry logic.
How to Use the Tool
- Browse the full list of status codes organized by class (1xx, 2xx, 3xx, 4xx, 5xx).
- Search for a specific code number or keyword (e.g., "429" or "rate limit") using the search box.
- Click any status code to expand its full description: definition, RFC reference, common causes, and appropriate client handling.
- Use the filter buttons to show only a specific class of codes.
- Copy the status code number and description for use in API documentation or error handling code.
Key Features & Specifications
- Complete reference for all standard HTTP status codes from RFC 9110 and common extensions
- Search by code number or keyword description
- Filter by response class: 1xx, 2xx, 3xx, 4xx, 5xx
- Each entry includes RFC reference, common causes, and recommended client/server behavior
- Non-standard but widely used codes included (103 Early Hints, 418 I'm a Teapot, 451 Unavailable for Legal Reasons)
Frequently Asked Questions (FAQ)
- Q:What is the difference between 401 and 403?
- 401 Unauthorized means the client must authenticate (provide credentials) — despite the misleading name, it signals that authentication is missing or invalid, not that the client lacks permission. 403 Forbidden means the client is authenticated but does not have permission to access the resource — authentication would not help.
- Q:When should an API return 400 vs 422?
- 400 Bad Request indicates the request is syntactically malformed (invalid JSON, wrong Content-Type, missing required headers). 422 Unprocessable Entity (from WebDAV, widely adopted by REST APIs) indicates the request is syntactically valid but semantically invalid — for example, a required field is missing in a valid JSON body, or a value fails business validation rules.
- Q:What should happen when a 429 Too Many Requests is received?
- The client should implement exponential backoff with jitter: wait a period before retrying (often indicated by the Retry-After response header), doubling the wait on successive failures, and adding random jitter to prevent thundering-herd effects when many clients retry simultaneously.