HTTP Status Codes Reference
Complete HTTP status codes reference with descriptions and RFC specs.
61 codes
The server has received the request headers and the client should proceed to send the request body.
The server agrees to switch 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.
Used to return some response headers before the final HTTP message, allowing the client to preload resources.
The request succeeded. The meaning of success depends on the HTTP method used.
The request succeeded and a new resource was created. Typically used with POST or PUT.
The request has been accepted for processing, but processing has not been completed.
The returned metadata is not exactly the same as available from the origin server, but collected from a local or third-party copy.
The server successfully processed the request and is not returning any content.
The server successfully processed the request and asks the client to reset the document view.
The server is delivering only part of the resource due to a range header sent by the client.
The message body contains multiple separate response codes for multiple independent operations.
The members of a DAV binding have already been enumerated in a preceding part of the response.
The server has fulfilled a GET request and the response is a representation of the result of one or more instance-manipulations.
The request has more than one possible response. The user or user agent should choose one.
The URL of the requested resource has been changed permanently. The new URL is given in the response.
The URI of requested resource has been changed temporarily. Further changes in the URI might be made in the future.
The server sent this response to direct the client to get the requested resource at another URI with a GET request.
Used for caching. Tells the client that the response has not been modified, so the client can use the cached version.
The server sends this response to direct the client to get the requested resource at another URI with the same method.
The resource is now permanently located at another URI. Similar to 301 but the request method must not change.
The server cannot or will not process the request due to a client error such as malformed syntax.
The client must authenticate itself to get the requested response. Similar to 403 but authentication is possible.
Reserved for future use. Originally intended for digital payment systems.
The client does not have access rights to the content. Unlike 401, the client's identity is known to the server.
The server cannot find the requested resource. The URL is not recognized or the resource 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's headers.
Authentication is needed to be done by a proxy.
The server would like to shut down this unused connection. It is sent on an idle connection by some servers.
The request conflicts with the current state of the server, such as an edit conflict between multiple simultaneous updates.
The requested content has been permanently deleted from the server, with no forwarding address.
The server rejected the request because the Content-Length header field is not defined.
The client has indicated preconditions in its headers which the server does not meet.
The request entity is larger than limits defined by the server.
The URI requested by the client is longer than the server is willing to interpret.
The media format of the requested data is not supported by the server.
The range specified by the Range header field in the request cannot be fulfilled.
The expectation indicated by the Expect request header field cannot be met by the server.
The server refuses the attempt to brew coffee with a teapot. An April Fools' joke from RFC 2324.
The request was directed at a server that is not able to produce a response.
The request was well-formed but was unable to be followed due to semantic errors.
The resource that is being accessed is locked.
The request failed because it depended on another request and that request failed.
The server is unwilling to risk processing a request that might be replayed.
The server refuses to perform the request using the current protocol but might do so after the client upgrades.
The origin server requires the request to be conditional to prevent lost-update problems.
The user has sent too many requests in a given amount of time (rate limiting).
The server is unwilling to process the request because its header fields are too large.
The user agent requested a resource that cannot legally be provided, such as a web page censored by a government.
The server has encountered a situation it does not know how to handle.
The request method is not supported by the server and cannot be handled.
The server, while working as a gateway, got an invalid response from the upstream server.
The server is not ready to handle the request. Common causes are a server that is down for maintenance or overloaded.
The server is acting as a gateway and cannot get a response in time from the upstream server.
The HTTP version used in the request is not supported by the server.
The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself.
The method could not be performed on the resource because the server is unable to store the representation needed.
The server detected an infinite loop while processing the request.
Further extensions to the request are required for the server to fulfill it.
The client needs to authenticate to gain network access.
What Are HTTP Status Codes?
HTTP status codes are three-digit numbers that a server returns in response to every HTTP request. They tell the client whether the request succeeded, needs further action, or failed — and why. Status codes are defined in RFC 9110 and grouped into five classes based on their first digit: 1xx informational, 2xx success, 3xx redirection, 4xx client error, and 5xx server error. Understanding status codes is essential for debugging APIs, configuring web servers, and building reliable HTTP clients.
How to Use This Reference
- Type a code number (e.g. 404) or keyword (e.g. timeout) in the search box to filter the list.
- Use the 1xx–5xx buttons to filter by status class.
- Each entry shows the code, name, description, and the RFC that defines it.
Status Code Classes
- 1xx Informational — The request was received and the process is continuing.
- 2xx Success — The request was successfully received, understood, and accepted.
- 3xx Redirection — Further action must be taken to complete the request.
- 4xx Client Error — The request contains bad syntax or cannot be fulfilled by the server.
- 5xx Server Error — The server failed to fulfill an apparently valid request.
FAQ
What are HTTP status codes?
HTTP status codes are three-digit numbers returned by a server in response to a client request. They indicate whether the request was successful, redirected, or resulted in an error. Codes are grouped into five classes: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), and 5xx (server error).
What is the difference between 401 and 403?
401 Unauthorized means the client must authenticate — the server does not know who you are. 403 Forbidden means the server knows who you are but you do not have permission to access the resource.
What is the difference between 301 and 302?
301 Moved Permanently tells clients and search engines that the resource has moved forever — update your bookmarks and links. 302 Found is a temporary redirect — the resource is temporarily at a different URL, so keep using the original URL.
What does 429 Too Many Requests mean?
429 Too Many Requests means the client has sent too many requests in a given time window. The server is rate-limiting the client. The response often includes a Retry-After header indicating when to try again.