// look up any http status code in one click
Complete HTTP status codes reference with descriptions, use cases, and examples. Search and filter all 1xx, 2xx, 3xx, 4xx, and 5xx codes instantly.
Type a code number or name in the search box, or click a category filter (1xx–5xx) to narrow results.
Click on any status code card to open a detail panel with full description and use cases.
Copy the code number or click the MDN link for the official specification.
HTTP status codes are 3-digit numbers returned by a server in response to a client's request. They are grouped into five classes: informational (1xx), success (2xx), redirection (3xx), client errors (4xx), and server errors (5xx). This tool provides a complete, searchable reference for all standard codes defined in RFC 7231 and related specifications.
401 Unauthorized means the client is not authenticated — they need to log in or provide valid credentials. 403 Forbidden means the client is authenticated but does not have permission to access the resource. Think of 401 as "who are you?" and 403 as "I know who you are, but you can't come in."
Use 301 (Moved Permanently) when a resource has permanently moved to a new URL — search engines will update their index. Use 302 (Found/Temporary Redirect) when the redirect is temporary and the original URL may be used again in the future. For modern APIs, 307 and 308 are preferred as they preserve the HTTP method.
404 Not Found means the server could not locate the requested resource. This can happen because the URL is wrong, the page has been deleted, or it never existed. A 404 is a client error — meaning the problem is with the request, not the server.
500 Internal Server Error is a generic catch-all for unexpected server failures — something went wrong on the server side with no more specific information. 503 Service Unavailable means the server is temporarily unable to handle the request, typically due to maintenance or overload, and the issue should resolve itself.
204 No Content is returned when a request succeeds but there is no content to return in the body. It's commonly used for DELETE operations, form submissions where no redirect is needed, or PUT/PATCH operations that don't need to return the updated resource.
Use 400 Bad Request for syntactically malformed requests (invalid JSON, missing required headers). Use 422 Unprocessable Entity when the request is syntactically correct but semantically invalid — for example, a valid JSON body where a field value fails business logic validation.
429 Too Many Requests is returned when a client has sent too many requests in a given time period — this is rate limiting. Servers typically include a Retry-After header indicating how long the client should wait before making another request.
Yes. While most codes are standardized in RFC 7231 and related RFCs, some non-standard codes exist in practice. For example, 418 (I'm a Teapot) is an April Fools' joke from RFC 2324, and Cloudflare uses custom codes like 520 (Unknown Error) and 522 (Connection Timed Out). This tool covers all standard IANA-registered codes.
HTTP status codes are three-digit integers returned by a web server in response to every HTTP request. They are the primary mechanism for a server to communicate the outcome of a request back to the client — whether that's a browser, mobile app, or API consumer. Every developer working with web technologies encounters these codes daily, yet their nuances are often misunderstood. This reference covers all standard codes grouped by class, with descriptions, use cases, and example headers.
The HTTP/1.1 specification (RFC 7231) divides status codes into five classes based on their first digit. Understanding which class a code belongs to immediately tells you the nature of the response:
While there are over 60 registered HTTP status codes, a handful make up the vast majority of responses you'll encounter in real-world applications:
Proper use of HTTP status codes is a cornerstone of well-designed REST APIs. A common mistake is returning 200 OK for every response and embedding error information in the body — this forces clients to parse the body to detect failures and breaks conventions that HTTP clients, proxies, and monitoring tools rely on.
Best practices for REST API status codes include: using 201 Created (not 200) when a resource is successfully created via POST; returning 204 No Content for successful DELETE operations; using 422 Unprocessable Entity for validation errors rather than the generic 400; and always including a Retry-After header with 429 and 503 responses to help clients implement backoff strategies.
The 3xx class and the 304 status play a critical role in HTTP caching. When a client has a cached version of a resource, it can send a conditional request using the If-None-Match (ETag) or If-Modified-Since headers. If the server determines the cached version is still current, it returns 304 Not Modified with an empty body — saving bandwidth and reducing latency significantly. Understanding the distinction between 301 (permanent) and 302 (temporary) redirects is also crucial for SEO: search engines pass link equity through 301s but not 302s.
For 4xx errors, always return a descriptive error body in addition to the status code. The body should include a machine-readable error code, a human-readable message, and optionally a field-level breakdown for validation errors. For 5xx errors, return enough information for developers to report and debug issues, but avoid exposing internal implementation details like stack traces in production environments.
Consider implementing a consistent error response schema across your entire API. Libraries like Problem Details for HTTP APIs (RFC 7807) provide a standardized format using application/problem+json content type that includes fields like type, title, status, detail, and instance.
Several status codes were introduced by WebDAV (RFC 4918) and are now widely used beyond their original context. 207 Multi-Status returns multiple status codes in a single response body, useful for batch operations. 422 Unprocessable Entity has been widely adopted for API validation errors. 423 Locked and 424 Failed Dependency are more niche but appear in collaborative editing and dependency-heavy workflows.