HTTP Status Code Reference
HTTP status codes indicate the result of server requests. Categories: 1xx (informational), 2xx (success), 3xx (redirect), 4xx (client error), 5xx (server error). Common codes: 200 (OK - success), 201 (Created), 204 (No Content), 301 (Moved Permanently - permanent redirect), 302 (Found - temporary redirect), 304 (Not Modified - cached), 400 (Bad Request - invalid syntax), 401 (Unauthorized - auth required), 403 (Forbidden - no permission), 404 (Not Found), 429 (Too Many Requests - rate limited), 500 (Internal Server Error), 502 (Bad Gateway), 503 (Service Unavailable). Use in API design, debugging, and web development.
Complete reference of all HTTP status codes (1xx–5xx). Search and filter by category, view descriptions and common use cases, and copy code + message instantly. Color-coded by category with highlighted common codes.
Showing 61 status codes
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.
Used to return response headers before the final HTTP message, allowing the browser to preload resources.
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 from the origin server but from a local or third-party copy.
The server has fulfilled the request but does not need to return a body.
The server fulfilled 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.
Conveys information about multiple resources in situations where multiple status codes might be appropriate.
Used inside a DAV: propstat response to avoid repeatedly enumerating internal members of multiple bindings.
The server has fulfilled a GET request and the response is a representation of the result of instance-manipulations applied to the current instance.
The request has more than one possible response and the user or user agent should choose one.
The requested resource has been permanently moved to a new URL. Search engines update their index.
The requested resource temporarily resides at a different URL. The client should continue using the original 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. The client can use the cached version.
The request should be repeated with another URL, but future requests should still use the original URL. The method and body are not changed.
The resource has been permanently moved. Like 301 but the method and body are not changed.
The server cannot process the request due to a client error such as malformed syntax or invalid parameters.
The request requires user authentication. The client must include valid credentials.
Reserved for future use. Originally intended for digital payment systems.
The server understood the request but refuses to authorize it. Authentication will not help.
The server cannot find the requested resource. The URL is not recognized.
The HTTP method used is not supported for the requested resource.
The server cannot produce a response matching the Accept headers sent by the client.
The client must first authenticate with the proxy server.
The server timed out waiting for the request from the client.
The request conflicts with the current state of the server resource.
The resource is no longer available and will not be available again. Unlike 404, this is permanent.
The server requires the Content-Length header to be specified in the request.
One or more conditions in the request header fields evaluated to false.
The request body is larger than the server is willing or able to process.
The URI provided in the request is too long for the server to process.
The server refuses the request because the payload format is not supported.
The range specified in the Range header cannot be fulfilled.
The expectation given in the Expect request header could not be met by the server.
An April Fools' joke from RFC 2324. The server refuses to brew coffee because it is a teapot.
The request was directed at a server that is not able to produce a response.
The server understands the content type and syntax but cannot process the contained instructions.
The resource that is being accessed is locked.
The request failed because it depended on another request that also failed.
The server is unwilling to process a request that might be replayed.
The server refuses to perform the request using the current protocol but might after the client upgrades.
The server requires the request to be conditional to prevent lost updates.
The user has sent too many requests in a given amount of time (rate limiting).
The server refuses the request because the header fields are too large.
The resource is unavailable due to legal demands such as government censorship or court order.
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, acting as a gateway or proxy, received an invalid response from the upstream server.
The server is not ready to handle the request, usually due to maintenance or overload.
The server, acting as a gateway or proxy, did not receive a timely response 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 content negotiation itself.
The server is unable to store the representation needed to complete the request.
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, typically for captive portals.
How to Use
- Enter your value in the input field
- Click the Calculate/Convert button
- Copy the result to your clipboard
Frequently Asked Questions
- What are HTTP status codes?
- HTTP status codes are three-digit numbers returned by a web server to indicate the result of a client's request. They are grouped into five classes: 1xx (Informational), 2xx (Success), 3xx (Redirection), 4xx (Client Error), and 5xx (Server Error). For example, 200 means the request succeeded, 404 means the resource was not found, and 500 means the server encountered an error.
- What is the difference between 301 and 302 redirects?
- A 301 redirect means the resource has permanently moved to a new URL — search engines will update their index to the new URL and pass link equity. A 302 redirect means the resource is temporarily at a different URL — search engines keep the original URL indexed. Use 301 for permanent URL changes (domain migration, restructuring) and 302 for temporary situations (maintenance, A/B testing).
- What is the difference between 401 and 403?
- 401 Unauthorized means the client has not provided valid authentication credentials — the request can be retried with proper credentials (e.g., a login token). 403 Forbidden means the server understood the request and the client may be authenticated, but the client does not have permission to access the resource. Re-authenticating will not help with a 403.
- What is the difference between 404 and 410?
- 404 Not Found means the server cannot find the resource — it may exist in the future or the URL may be wrong. 410 Gone means the resource previously existed but has been intentionally and permanently removed. Search engines treat 410 as a stronger signal to deindex the page compared to 404.
- What causes a 502 Bad Gateway error?
- A 502 Bad Gateway error occurs when a server acting as a gateway or proxy (like Nginx or a load balancer) receives an invalid or no response from the upstream backend server. Common causes include: the backend application crashed, the backend is overloaded and not responding, network issues between the proxy and backend, or misconfigured proxy settings.
- What should I do when I get a 429 Too Many Requests error?
- A 429 error means you have exceeded the API's rate limit. Check the Retry-After response header for how long to wait before retrying. Implement exponential backoff in your code — wait 1s, then 2s, then 4s between retries. Consider caching responses, reducing request frequency, or upgrading to a higher API tier if available.