HTTP Status Code Lookup
Comprehensive reference for HTTP status codes. Look up any status code meaning, understand response codes, and learn about HTTP error codes.
Continue
The server has received the request headers and the client should proceed to send the request body.
Switching Protocols
The requester has asked the server to switch protocols and the server has agreed.
Processing
A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request.
Early Hints
Used to return some response headers before final HTTP message.
OK
The request is successful. The meaning of success depends on the HTTP method used.
Created
The request has been fulfilled and a new resource has been created.
Accepted
The request has been accepted for processing, but the processing has not been completed.
Non-Authoritative Information
The request was successful but the information may have been modified by a transforming proxy.
No Content
The server successfully processed the request but is not returning any content.
Reset Content
The server successfully processed the request but is not returning any content and requires the requester to reset the document view.
Partial Content
The server is delivering only part of the resource due to a range header sent by the client.
Multi-Status
Provides status for multiple independent operations.
Already Reported
The members of a DAV binding have already been enumerated in a preceding part of the multistatus response.
IM Used
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.
Multiple Choices
The request has more than one possible response. The user agent should choose one of them.
Moved Permanently
The URL of the requested resource has been changed permanently. The new URL is given in the response.
Found
The URL of the requested resource has been changed temporarily. Further changes in the URL might be made in the future.
See Other
The server sent this response to direct the client to get the requested resource at another URI with a GET request.
Not Modified
Used for caching purposes. The client can use cached version of the response.
Use Proxy
The requested resource is available only through a proxy.
Unused
This response code is no longer used and is reserved.
Temporary Redirect
The server sends this response to direct the client to get the requested resource at another URI with the same method.
Permanent Redirect
This means the resource is now permanently located at another URI.
Bad Request
The server could not understand the request due to invalid syntax.
Unauthorized
Authentication is required and has failed or has not yet been provided.
Payment Required
This response code is reserved for future use and was originally created for digital payment systems.
Forbidden
The client does not have access rights to the content; the server is refusing to give the requested resource.
Not Found
The server can not find the requested resource. This is the most common error on the internet.
Method Not Allowed
The request method is known by the server but is not supported by the target resource.
Not Acceptable
The server cannot produce a response matching the list of acceptable values defined in the request's headers.
Proxy Authentication Required
This is similar to 401 but authentication is required to be done by a proxy.
Request Timeout
The server timed out waiting for the request. The client did not produce a request within the time the server was prepared to wait.
Conflict
This response is sent when a request conflicts with the current state of the server.
Gone
The requested content has been permanently deleted from the server with no forwarding address.
Length Required
The server rejects the request because the Content-Length header field is not defined and the server requires it.
Precondition Failed
The client has indicated preconditions in its headers which the server does not meet.
Payload Too Large
The request entity is larger than limits defined by the server.
URI Too Long
The URI requested by the client is longer than the server is willing to interpret.
Unsupported Media Type
The media format of the requested data is not supported by the server.
Range Not Satisfiable
The range specified by the Range header field in the request cannot be fulfilled.
Expectation Failed
The expectation indicated by the Expect request header field cannot be met by the server.
I'm a teapot
This code was defined in 1998 as one of the traditional IETF April Fools' jokes.
Misdirected Request
The request was directed at a server that is not able to produce a response.
Unprocessable Entity
The request was well-formed but was unable to be followed due to semantic errors.
Locked
The resource that is being accessed is locked.
Failed Dependency
The request failed because it depended on another request and that request failed.
Too Early
Indicates that the server is unwilling to risk processing a request that might be replayed.
Upgrade Required
The server refuses to perform the request using the current protocol.
Precondition Required
The origin server requires the request to be conditional.
Too Many Requests
The user has sent too many requests in a given amount of time.
Request Header Fields Too Large
The server is unwilling to process the request because its header fields are too large.
Unavailable For Legal Reasons
The server is denying access to the resource as a consequence of a legal demand.
Internal Server Error
The server has encountered a situation it does not know how to handle.
Not Implemented
The request method is not supported by the server and cannot be handled.
Bad Gateway
The server, while acting as a gateway or proxy, received an invalid response from an upstream server.
Service Unavailable
The server is not ready to handle the request. Common causes are a server that is down for maintenance or is overloaded.
Gateway Timeout
The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
HTTP Version Not Supported
The HTTP version used in the request is not supported by the server.
Variant Also Negotiates
The server has an internal configuration error.
Insufficient Storage
The method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request.
Loop Detected
The server detected an infinite loop while processing the request.
Not Extended
Further extensions to the request are required for the server to fulfill it.
Network Authentication Required
The client needs to authenticate to gain network access.
How to Use This HTTP Status Code Lookup Tool
Our HTTP status code lookup tool provides a comprehensive reference for all HTTP status codes. Use it to quickly find information about any status code:
- Search for status codes by entering a code number (like '404'), status name (like 'not found'), or description keywords
- Filter by category using the category buttons to view only informational, success, redirection, client error, or server error codes
- Click on any status code card to expand and view detailed information including description, common use cases, and RFC reference
- Use the copy button to copy status codes for use in documentation, code comments, or API specifications
For more developer tools, check out our Toolbox homepage or explore related tools like our JSON Formatter and Hash Generator for API development workflows.
What Are HTTP Status Codes?
HTTP status code lookup is essential for web developers, API designers, and anyone working with web technologies. HTTP status codes are three-digit numbers returned by web servers to indicate the outcome of an HTTP request. These codes provide critical information about whether a request was successful, if an error occurred, or if additional action is needed.
When you visit a website or make an API call, the server responds with an HTTP status code along with the requested resource or an error message. Status codes are grouped into five main categories based on their first digit: informational responses (1xx), successful responses (2xx), redirections (3xx), client errors (4xx), and server errors (5xx). Understanding these codes helps developers debug issues, implement proper error handling, and create better user experiences.
Knowing HTTP status codes is crucial for building robust web applications and APIs. Proper use of status codes improves error handling, enables better debugging, enhances API documentation, and helps create more intuitive error messages for end users. Our HTTP status code lookup tool provides a comprehensive reference for all standard and extended status codes.
The official HTTP status code specifications are defined in RFC 7231 and related RFC documents maintained by the Internet Engineering Task Force (IETF). For comprehensive documentation, refer to the MDN HTTP Status Codes reference.
HTTP Status Code Categories
HTTP status codes are organized into five main categories. Each category serves a specific purpose in HTTP communication:
1xx Informational Responses
Informational responses (100-199) indicate that the request was received and the process is continuing. These are provisional responses used during the request processing phase. Examples include 100 Continue, which tells the client to continue sending the request body, and 101 Switching Protocols, used when upgrading to a different protocol like WebSocket.
2xx Success Responses
Success responses (200-299) indicate that the request was successfully received, understood, and accepted. The most common success code is 200 OK, which means the request succeeded. Other important success codes include 201 Created (for resource creation), 204 No Content (for successful operations with no response body), and 206 Partial Content (for range requests in file downloads).
3xx Redirection Responses
Redirection responses (300-399) indicate that further action needs to be taken to complete the request. These codes are used when a resource has moved or when alternative locations should be used. Common redirect codes include 301 Moved Permanently (for permanent URL changes and SEO), 302 Found (temporary redirect), and 304 Not Modified (for caching optimization).
4xx Client Error Responses
Client error responses (400-499) indicate that there was an error with the request. These errors are the client's responsibility, meaning the request was malformed, unauthorized, or the requested resource doesn't exist. The most famous client error is 404 Not Found. Other important codes include 400 Bad Request (invalid syntax), 401 Unauthorized (authentication required), 403 Forbidden (permission denied), and 429 Too Many Requests (rate limiting).
5xx Server Error Responses
Server error responses (500-599) indicate that the server failed to fulfill a valid request. These errors are the server's responsibility and often indicate problems with the server configuration, database, or application logic. Common server errors include 500 Internal Server Error (generic server failure), 502 Bad Gateway (invalid response from upstream server), 503 Service Unavailable (server temporarily down), and 504 Gateway Timeout (upstream server timeout).
Most Common HTTP Status Codes Explained
While there are dozens of HTTP status codes, certain codes are encountered more frequently in web development. Understanding these common codes is essential for effective debugging and error handling:
200 OK
200 OK is the standard success response for HTTP requests. It indicates that the request succeeded and the response contains the requested resource. This is the most common status code you'll encounter in successful API calls and web page loads. The response body typically contains the requested data, HTML, JSON, or other content types.
201 Created
201 Created indicates that a new resource was successfully created as a result of the request. This code is typically used in response to POST requests that create new resources. The response usually includes a Location header pointing to the newly created resource. This is standard practice in RESTful API design for resource creation endpoints.
301 Moved Permanently
301 Moved Permanently indicates that the requested resource has permanently moved to a new URL. This is crucial for SEO, as search engines will update their indexes to point to the new location. When implementing 301 redirects, always ensure the new URL is correct, as browsers and search engines will cache this redirect permanently. Use this for permanent URL changes, domain migrations, or when consolidating duplicate content.
404 Not Found
404 Not Found is perhaps the most recognizable HTTP status code. It indicates that the server cannot find the requested resource. This doesn't mean the resource is permanently gone (that would be 410 Gone), but rather that it doesn't exist at the specified location. Common causes include broken links, deleted pages, incorrect URLs, or missing files. When implementing error pages, always provide helpful navigation options and search functionality to help users find what they're looking for.
500 Internal Server Error
500 Internal Server Error is a generic server error indicating that something went wrong on the server side, but the server couldn't be more specific about what the problem was. This code should be used when an unexpected condition occurred that prevented the server from fulfilling the request. It's important to log these errors on the server for debugging purposes, as they indicate problems that need to be addressed in the application code or server configuration.
HTTP Status Codes in API Development
Proper use of HTTP status codes is fundamental to building well-designed REST APIs. Status codes communicate the result of API operations clearly and consistently, making APIs easier to understand and integrate with:
- Consistency: Using appropriate status codes consistently across your API helps developers understand and integrate with your API more easily. Follow REST conventions and HTTP standards to ensure predictable behavior.
- Error Handling: Different status codes help client applications handle errors appropriately. 4xx errors indicate client-side issues that the client can potentially fix (like invalid input), while 5xx errors indicate server-side problems that require server intervention.
- Documentation: Documenting which status codes your API endpoints can return helps developers implement proper error handling. Include status codes in your API documentation, OpenAPI specifications, and code examples.
- Client Experience: Well-chosen status codes improve the client experience by providing clear, actionable information. For example, a 429 Too Many Requests response with a Retry-After header gives clients specific guidance on when to retry their request.
HTTP Status Codes Best Practices
Following best practices for HTTP status codes improves the reliability, maintainability, and usability of web applications and APIs:
- Choose Appropriate Codes: Select status codes that accurately reflect the outcome of the request. Don't use 200 OK for error conditions or 500 for client errors. Use the most specific code that accurately describes the situation.
- Provide Error Details: When returning error status codes (4xx, 5xx), include detailed error messages in the response body. This helps developers debug issues and provides better error handling capabilities. Include error codes, descriptions, and potentially suggested solutions.
- Logging and Monitoring: Log all non-2xx status codes for monitoring and debugging purposes. Track error rates, identify patterns, and set up alerts for unusual error spikes. This helps identify issues before they significantly impact users.
- Monitoring: Use status code monitoring to track application health. High rates of 5xx errors indicate server problems, while high rates of 4xx errors might indicate client-side issues, API misuse, or documentation problems that need attention.
Troubleshooting Common Status Code Issues
Understanding how to troubleshoot issues based on HTTP status codes is an essential skill for web developers and system administrators:
Client Errors (4xx): When encountering 4xx errors, check the request format, authentication credentials, authorization permissions, and whether the requested resource exists. Review request headers, query parameters, and request body format. Common fixes include correcting URLs, providing proper authentication, fixing request syntax, and ensuring resources exist.
For 400 Bad Request, validate input data and check request format. For 401 Unauthorized, verify authentication tokens or credentials. For 403 Forbidden, check user permissions and authorization rules. For 404 Not Found, verify the resource URL and existence. For 429 Too Many Requests, implement rate limiting or wait before retrying.
Server Errors (5xx): 5xx errors indicate server-side problems that require investigation. Check server logs, database connectivity, application code, server configuration, and system resources. These errors typically require developer or system administrator intervention to resolve.
For 500 Internal Server Error, check application logs for exceptions, verify database connections, and review recent code changes. For 502 Bad Gateway, check upstream server health and proxy configuration. For 503 Service Unavailable, verify server capacity, check for maintenance operations, and review resource constraints. For 504 Gateway Timeout, check upstream server response times and timeout configurations.