HTTP Status Code Reference
A complete, searchable reference for all HTTP status codes from 100 to 511. Browse by category, search by keyword or code number, and expand any code for full details including practical usage guidance and RFC specifications - all in your browser with no signup.
1xx Informational
(4)The server has received the request headers and the client should proceed to send the request body.
The server is switching protocols as requested by the client via the Upgrade header.
The server has received and is processing the request, but no response is available yet.
The server is sending preliminary headers to allow the client to preload resources before the final response.
2xx Success
(10)The request has succeeded. The meaning depends on the HTTP method used.
The request has been fulfilled and a new resource has been created.
The request has been accepted for processing, but the processing has not been completed.
The returned metadata is not exactly the set available from the origin server but is gathered from a local or third-party copy.
The server has fulfilled the request but does not need to return a response body.
The server has fulfilled the request and the user agent should reset the document view.
The server is delivering only part of the resource due to a Range header sent by the client.
Provides status for multiple independent operations in WebDAV.
The members of a DAV binding have already been enumerated in a previous reply to this request.
The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.
3xx Redirection
(9)The request has more than one possible response. The user agent or user should choose one.
The resource has been permanently moved to a new URL indicated by the Location header.
The resource has been temporarily moved to a different URL.
The response to the request can be found at another URL using a GET method.
The resource has not been modified since the last request, and the client should use its cached version.
The requested resource must be accessed through the proxy specified in the Location header.
Subsequent requests should use the specified proxy.
The resource has been temporarily moved, and the client should use the same HTTP method for the redirect.
The resource has been permanently moved, and the client should use the same HTTP method for the redirect.
4xx Client Error
(29)The server cannot process the request due to a client error (malformed syntax, invalid request message framing, or deceptive request routing).
The request requires user authentication. The response must include a WWW-Authenticate header.
This response code is reserved for future use. Originally intended for digital payment systems.
The client does not have access rights to the content, and the server is refusing to respond.
The server cannot find the requested resource. In an API, this can also mean the endpoint is valid but the resource itself does not exist.
The request method is known by the server but is not supported by the target resource.
The server cannot produce a response matching the list of acceptable values defined in the request headers.
The client must first authenticate itself with the proxy.
The server timed out waiting for the request.
The request conflicts with the current state of the server.
The requested resource is no longer available and will not be available again.
The server refuses to accept the request without a defined Content-Length header.
One or more conditions given in the request header fields evaluated to false.
The request entity is larger than the server is willing or able to process.
The URI provided in the request was too long for the server to process.
The media format of the requested data is not supported by the server.
The range specified in the Range header cannot be satisfied.
The expectation indicated by the Expect request header field cannot be met by the server.
The server refuses to brew coffee because it is, permanently, a teapot.
The request was directed at a server that cannot produce a response for the target resource.
The request body contains well-formed but semantically erroneous content.
The resource that is being accessed is locked.
The request failed because it depended on another operation that failed.
The server is unwilling to risk processing a request that might be replayed.
The client should switch to a different protocol as specified in the Upgrade header.
The server requires the request to be conditional to prevent the lost update problem.
The user has sent too many requests in a given amount of time (rate limiting).
The server refuses to process the request because the header fields are too large.
The resource is unavailable due to legal demands (government censorship, copyright claims).
5xx Server Error
(11)The server encountered an unexpected condition that prevented it from fulfilling the request.
The server does not support the functionality required to fulfill the request.
The server, while acting as a gateway or proxy, received an invalid response from the upstream server.
The server is currently unable to handle the request due to temporary overload or maintenance.
The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server.
The server does not support the HTTP protocol version used in the request.
The server has an internal configuration error and the chosen variant resource is configured to engage in transparent content negotiation itself.
The server is unable to store the representation needed to complete the request.
The server detected an infinite loop while processing a request with "Depth: infinity".
Further extensions to the request are required for the server to fulfill it.
The client needs to authenticate to gain network access (e.g., captive portal).
Why Use Our HTTP Status Code Reference?
A complete, developer-friendly reference with every standard HTTP status code from 1xx to 5xx, including WebDAV and experimental codes.
Complete Code Coverage
Every standard HTTP status code from 100 to 511, including informational, success, redirection, client error, and server error categories. Plus WebDAV codes and experimental status codes - all in one place.
Powerful Search & Filter
Search by code number, title, description, usage notes, or RFC specification. Filter by category (1xx-5xx) or view all codes at once. The search updates in real time across the entire dataset.
Detailed Expandable Cards
Click any status code to expand detailed information including full description, practical usage notes, RFC specification reference, and copy functionality - keeping the compact view clean and scannable.
One-Click Copy & Reference
Copy any status code with its title directly to your clipboard with a single click. Each code shows its RFC specification source and category for easy citation in documentation, code reviews, and debugging.
Who Uses HTTP Status Code References?
From frontend developers to API designers, quick access to accurate HTTP status code information is essential.
Web Developers
Return the correct status codes from backend APIs. Know when to use 201 vs 202, 400 vs 422, or 301 vs 308 in your Express, Django, Rails, or ASP.NET application.
API Designers
Design RESTful APIs with precise status code semantics. Choose appropriate codes for CRUD operations, error responses, rate limiting, and content negotiation strategies.
Debugging & QA
Quickly look up unfamiliar status codes encountered during debugging, API testing with Postman/cURL, log analysis, or when reviewing server error reports.
DevOps & SRE
Interpret HTTP status codes in load balancer logs, CDN reports, monitoring dashboards, and uptime alerts. Understand 502 vs 504 when diagnosing gateway issues.
Students & Learners
Study HTTP protocol fundamentals with clear, practical explanations. Learn the difference between 4xx and 5xx errors, when redirections happen, and how caching uses 304.
Technical Writers
Reference accurate status code descriptions, spec references, and usage notes when writing API documentation, tutorials, error handbooks, and coding guides.
About HTTP Status Codes
HTTP status codes are three-digit response codes that servers send to indicate the result of a client’s request. They are defined in the HTTP specification maintained by the Internet Engineering Task Force (IETF).
What Are HTTP Status Codes?
HTTP status codes are standardised three-digit numbers returned by web servers as part of every HTTP response. They are grouped into five classes, indicated by the first digit: 1xx (Informational), 2xx (Success), 3xx (Redirection), 4xx (Client Error), and 5xx (Server Error). Each code conveys a specific condition about the request, allowing clients (browsers, APIs, mobile apps) to determine the appropriate next action. The current HTTP specification (RFC 9110) defines the core semantics, with additional codes defined in companion RFCs for WebDAV, rate limiting, legal restrictions, and other specialised use cases.
How Our Reference Works
- Browse by Category: Use the filter buttons to view only Informational (1xx), Success (2xx), Redirection (3xx), Client Error (4xx), or Server Error (5xx) codes.
- Search: Type any code number, title keyword, or term like “cache” or “redirect” to find relevant codes instantly across the entire dataset.
- Expand for Details: Click any status code card to see the full description, practical usage guidance, and RFC specification reference.
- Copy & Reference: Click the copy button on any code to copy it with its title for use in code, documentation, or debugging notes.
Understanding Status Code Categories
- 1xx Informational (100-199): Provisional responses indicating that the server has received the request and is continuing to process it. These are interim responses before the final response.
- 2xx Success (200-299): The request was successfully received, understood, and accepted. The specific code indicates what was done with the request (created, accepted, partially delivered).
- 3xx Redirection (300-399): Further action must be taken by the client to complete the request. Usually means the resource has moved, and the client should follow the URL in the Location header.
- 4xx Client Error (400-499): The request contains bad syntax or cannot be fulfilled by the server. These errors are the client’s responsibility - invalid input, authentication failure, resource not found.
- 5xx Server Error (500-599): The server failed to fulfill a valid request due to an internal error, capacity issue, or upstream failure. The client may retry the request later.
Privacy, Security & Availability
This HTTP Status Code Reference is a static reference tool. No data is sent, stored, or processed on any server. The complete status code dataset is embedded in the page and loads instantly without any network requests. No account, no signup, and no tracking. The tool is 100% free to use with no usage limits.
Frequently Asked Questions
Everything you need to know about HTTP status codes and our reference tool.
Our reference includes over 50 standard HTTP status codes from 1xx to 5xx, covering the core RFC 9110 specification, WebDAV extensions (RFC 4918, 5842), rate limiting (RFC 6585), legal restrictions (RFC 7725), and experimental codes.
Yes, deprecated codes like 305 (Use Proxy) and 306 (Switch Proxy) are included with notes about their deprecation status and historical context.
Yes. The search covers all fields including the RFC spec reference. Searching for "RFC 6585" will find all rate limiting related codes (428, 429, 431).
Five standard categories by first digit: 1xx Informational, 2xx Success, 3xx Redirection, 4xx Client Error, and 5xx Server Error. Each category has its own colour coding for quick visual identification.
Yes. Click the copy button on any code card to copy the code number and title (e.g., "200 OK") to your clipboard. Perfect for use in code, documentation, or bug reports.
400 (Bad Request) is used for malformed syntax or invalid request structure. 422 (Unprocessable Content) means the request body is well-formed but semantically incorrect - like an email format validation failure.
Some ranges have overlapping or extended codes. For example, 4xx has both standard HTTP codes and WebDAV-specific codes (423 Locked, 424 Failed Dependency) that serve different use cases.
Yes, 100% free with no limits, no signup, no account, and no hidden charges. Use it as much as you need for development, debugging, and learning.