HTTP Status Codes
Every HTTP status code, filterable and searchable with plain-English explanations.
The server has received the request headers and the client should proceed to send the request body.
The requester has asked the server to switch protocols and the server has agreed.
The server has received the request and is processing it, but no response is available yet (WebDAV).
Used to return some response headers before the final response message.
The request succeeded. The result depends on the HTTP method used.
The request succeeded and a new resource was created, typically after a POST or PUT.
The request has been received but not yet acted upon. Used for asynchronous processing.
The returned metadata is not from the origin server but from a local or third-party copy.
The request succeeded but there is no content to send back. Common for DELETE or PUT.
The server asks the client to reset the document view that sent the request.
The server is delivering only part of the resource, used for range requests.
Conveys information about multiple resources in a single response (WebDAV).
The server has fulfilled a GET request with instance manipulations applied to the response.
The request has more than one possible response. The client should choose one of them.
The resource has been permanently moved to a new URL. Search engines update their index.
The resource is temporarily under a different URL. Future requests should still use the original URL.
The server redirects the client to a different URL to fetch the response, typically after a POST.
The cached version is still up to date. The client should use its local copy.
Like 302 but the HTTP method must not change on the redirected request.
Like 301 but the HTTP method must not change on the redirected request.
The server cannot process the request due to a client-side syntax error or malformed data.
The request requires authentication. The client must provide valid credentials.
Reserved for future use. Sometimes used for paid-access schemes.
The server understood the request but refuses to authorize it. Distinct from 401.
The server cannot find the requested resource. The most common client error on the web.
The HTTP method (GET, POST, etc.) is known by the server but not supported for this resource.
The resource cannot generate a response matching the Accept headers sent by the client.
The client must authenticate itself with a proxy before the request can proceed.
The server closed the connection because the client did not send the request in time.
The request conflicts with the current state of the server, such as a duplicate unique value.
The resource has been permanently deleted and will not come back. Like 404 but explicit.
The server requires a Content-Length header, which the client omitted.
A precondition in the request headers (such as If-Match) evaluated to false.
The request body exceeds the size limit the server is willing to accept.
The requested URL is longer than the server is willing to interpret.
The media format of the request data is not supported by the server.
The Range header in the request cannot be fulfilled by the server.
The expectation in the Expect header cannot be met by the server.
April Fools’ code from RFC 2324. The server refuses to brew coffee because it is a teapot.
The request was sent to a server that cannot produce a response (HTTP/2).
The request is well-formed but fails semantic validation (WebDAV). Common in REST APIs.
The resource being accessed is locked (WebDAV).
The request failed because it depended on another request that failed (WebDAV).
The server is unwilling to risk processing a request that might be a replay.
The client must upgrade to a different protocol (such as TLS).
The server requires the request to be conditional (include an If-Match header).
The client has sent too many requests in a given time (rate limiting).
The server refuses to process because the header fields are too large.
The resource is unavailable due to legal demands, such as government censorship.
A generic error message. The server encountered an unexpected condition.
The server does not support the functionality required to fulfill the request.
The server, acting as a gateway, received an invalid response from an upstream server.
The server is temporarily unavailable, usually due to overload or maintenance.
The gateway server did not receive a timely response from the upstream server.
The server does not support the HTTP protocol version used in the request.
Transparent content negotiation for the request results in a circular reference.
The server cannot store the representation needed to complete the request (WebDAV).
The server detected an infinite loop while processing the request (WebDAV).
Further extensions to the request are required for the server to fulfill it.
The client must authenticate to gain network access, such as a captive portal.
How to use the HTTP Status Codes reference
Every HTTP response carries a three-digit status code that tells the client what happened. The first digit defines the class \u2014 informational, success, redirection, client error or server error \u2014 and the next two narrow it down to a specific outcome. Use this reference to look up a code or pick the right one for your API.
- 01Type a number or keyword into the search box to find a code by value, name or description.
- 02Click a category (1xx to 5xx) to narrow the list to a single class of responses.
- 03Read the description. Use the code in your routes, error handlers or API responses as needed.
tips
- —For REST APIs, prefer 422 Unprocessable Entity over 400 when the JSON is valid but fails business validation.
- —Use 301 for permanent moves and 308 when you also need the method to stay the same after redirect.
- —A 304 Not Modified response, paired with ETag or Last-Modified headers, saves bandwidth by reusing the browser cache.
frequently asked
What do the first digits of an HTTP status code mean?+
The first digit defines the class: 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error. The remaining two digits identify the specific response within that class.
What is the difference between 401 Unauthorized and 403 Forbidden?+
401 means the request lacks valid authentication credentials — the client must log in. 403 means the server authenticated the client (or does not need to) but still refuses to authorize the action.
When should an API return 422 instead of 400?+
Return 400 when the request is malformed (bad syntax). Return 422 when the syntax is valid JSON but the data fails semantic validation, such as a missing required field or an invalid email format.
Is 418 I’m a Teapot a real status code?+
Yes. It was defined in RFC 2324 (the Hyper Text Coffee Pot Control Protocol) as an April Fools’ joke. Real servers should not return it, but some APIs use it playfully for refused requests.