Hubbry Logo
List of HTTP status codesList of HTTP status codesMain
Open search
List of HTTP status codes
Community hub
List of HTTP status codes
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
List of HTTP status codes
List of HTTP status codes
List of HTTP status codes
View on Wikipedia
from Wikipedia

HTTP
Request methods
Header fields
Response status codes
Security access control methods
Security vulnerabilities

Hypertext Transfer Protocol (HTTP) response status codes are issued by a server in response to a client's request made to the server. It includes codes from IETF Request for Comments (RFCs), other specifications, and some additional codes used in some common applications of the HTTP. The first digit of the status code specifies one of five standard classes of responses. The optional message phrases shown are typical, but any human-readable alternative may be provided, or none at all.

Unless otherwise stated, the status code is part of the HTTP standard.[1]

The Internet Assigned Numbers Authority (IANA) maintains the official registry of HTTP status codes.[2]

All HTTP response status codes are separated into five classes or categories. The first digit of the status code defines the class of response, while the last two digits do not have any classifying or categorization role. There are five classes defined by the standard:

  • 1xx informational response – the request was received, continuing process
  • 2xx successful – the request was successfully received, understood, and accepted
  • 3xx redirection – further action needs to be taken in order to complete the request
  • 4xx client error – the request contains bad syntax or cannot be fulfilled
  • 5xx server error – the server failed to fulfil an apparently valid request

1xx informational response

[edit]

An informational response indicates that the request was received and understood. It is issued on a provisional basis while request processing continues. It alerts the client to wait for a final response. The message consists only of the status line and optional header fields, and is terminated by an empty line. As the HTTP/1.0 standard did not define any 1xx status codes, servers must not[note 1] send a 1xx response to an HTTP/1.0 compliant client except under experimental conditions.

100 Continue
The server has received the request headers and the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). Sending a large request body to a server after a request has been rejected for inappropriate headers would be inefficient. To have a server check the request's headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. If the client receives an error code such as 403 (Forbidden) or 405 (Method Not Allowed) then it should not send the request's body. The response 417 Expectation Failed indicates that the request should be repeated without the Expect header as it indicates that the server does not support expectations (this is the case, for example, of HTTP/1.0 servers).[1]: §10.1.1 
101 Switching Protocols
The requester has asked the server to switch protocols and the server has agreed to do so.
102 Processing (WebDAV; RFC 2518)
A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet.[3] This prevents the client from timing out and assuming the request was lost. The status code is deprecated.[4]
103 Early Hints (RFC 8297)
Used to return some response headers before final HTTP message.[5]

2xx success

[edit]

This class of status codes indicates the action requested by the client was received, understood, and accepted.[2]

200 OK
Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request, the response will contain an entity describing or containing the result of the action.
201 Created
The request has been fulfilled, resulting in the creation of a new resource.[6]
202 Accepted
The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.
203 Non-Authoritative Information (since HTTP/1.1)
The server is a transforming proxy (e.g. a Web accelerator) that received a 200 OK from its origin, but is returning a modified version of the origin's response.[1]: §15.3.4 [1]: §7.7 
204 No Content
The server successfully processed the request, and is not returning any content.
205 Reset Content
The server successfully processed the request, asks that the requester reset its document view, and is not returning any content.
206 Partial Content
The server is delivering only part of the resource (byte serving) due to a range header sent by the client. The range header is used by HTTP clients to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.
207 Multi-Status (WebDAV; RFC 4918)
The message body that follows is by default an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.[7]
208 Already Reported (WebDAV; RFC 5842)
The members of a DAV binding have already been enumerated in a preceding part of the (multistatus) response, and are not being included again.
226 IM Used (RFC 3229)
The server has fulfilled a request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.[8]

3xx redirection

[edit]

This class of status code indicates the client must take additional action to complete the request. Many of these status codes are used in URL redirection.[2]

A user agent may carry out the additional action with no user interaction only if the method used in the second request is GET or HEAD. A user agent may automatically redirect a request. A user agent should detect and intervene to prevent cyclical redirects.[1]: §15.4 

300 Multiple Choices
Indicates multiple options for the resource from which the client may choose (via agent-driven content negotiation). For example, this code could be used to present multiple video format options, to list files with different filename extensions, or to suggest word-sense disambiguation.
301 Moved Permanently
This and all future requests should be directed to the given URI.
302 Found (Previously "Moved temporarily")
Tells the client to look at (browse to) another URL. The HTTP/1.0 specification required the client to perform a temporary redirect with the same method (the original describing phrase was "Moved Temporarily"),[9] but popular browsers implemented 302 redirects by changing the method to GET. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours.[1]: §15.4 
303 See Other (since HTTP/1.1)
The response to the request can be found under another URI using the GET method. When received in response to a POST (or PUT/DELETE), the client should presume that the server has received the data and should issue a new GET request to the given URI.
304 Not Modified
Indicates that the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match. In such case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.
305 Use Proxy (since HTTP/1.1)
The requested resource is available only through a proxy, the address for which is provided in the response. For security reasons, many HTTP clients (such as Mozilla Firefox and Internet Explorer) do not obey this status code.[10]
306 Switch Proxy
No longer used. Originally meant "Subsequent requests should use the specified proxy."
307 Temporary Redirect (since HTTP/1.1)
In this case, the request should be repeated with another URI; however, future requests should still use the original URI. In contrast to how 302 was historically implemented, the request method is not allowed to be changed when reissuing the original request. For example, a POST request should be repeated using another POST request.
308 Permanent Redirect
This and all future requests should be directed to the given URI. 308 parallels the behavior of 301, but does not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.

4xx client errors

[edit]
A The Wikimedia 404 message
404 error on Wikimedia

This class of status code is intended for situations in which the error seems to have been caused by the client. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents should display any included entity to the user.

400 Bad Request
The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing).
401 Unauthorized
Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication. 401 semantically means "unauthenticated", the user does not have valid authentication credentials for the target resource.
402 Payment Required
Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, as proposed, for example, by GNU Taler,[11] but that has not yet happened, and this code is not widely used. Google Developers API uses this status if a particular developer has exceeded the daily limit on requests.[12] Sipgate uses this code if an account does not have sufficient funds to start a call.[13] Shopify uses this code when the store has not paid their fees and is temporarily disabled.[14] Stripe uses this code for failed payments where parameters were correct, for example blocked fraudulent payments.[15]
403 Forbidden
The request contained valid data and was understood by the server, but the server is refusing action. This may be due to the user not having the necessary permissions for a resource or needing an account of some sort, or attempting a prohibited action (e.g. creating a duplicate record where only one is allowed). This code is also typically used if the request provided authentication by answering the WWW-Authenticate header field challenge, but the server did not accept that authentication. The request should not be repeated.
404 Not Found
The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.
405 Method Not Allowed
A request method is not supported for the requested resource; for example, a GET request on a form that requires data to be presented via POST, or a PUT request on a read-only resource.
406 Not Acceptable
The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request. See Content negotiation.
407 Proxy Authentication Required
The client must first authenticate itself with the proxy.
408 Request Timeout
The server timed out waiting for the request. According to HTTP specifications: "The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time."
409 Conflict
Indicates that the request could not be processed because of conflict in the current state of the resource, such as an edit conflict between multiple simultaneous updates.[16]
410 Gone
Indicates that the resource requested was previously in use but is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a "404 Not Found" may be used instead.
411 Length Required
The request did not specify the length of its content, which is required by the requested resource.
412 Precondition Failed
The server does not meet one of the preconditions that the requester put on the request header fields.
413 Payload Too Large
The request is larger than the server is willing or able to process. Previously called "Request Entity Too Large".[17]: §10.4.14 
414 URI Too Long
The URI provided was too long for the server to process. Often the result of too much data being encoded as a query-string of a GET request, in which case it should be converted to a POST request. Called "Request-URI Too Long" previously.[17]: §10.4.15 
415 Unsupported Media Type
The request entity has a media type which the server or resource does not support. For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.
416 Range Not Satisfiable
The client has asked for a portion of the file (byte serving), but the server cannot supply that portion. For example, if the client asked for a part of the file that lies beyond the end of the file. Called "Requested Range Not Satisfiable" previously.[17]: §10.4.17 
417 Expectation Failed
The server cannot meet the requirements of the Expect request-header field.[18]
418 I'm a teapot (RFC 2324, RFC 7168)
This code was defined in 1998 as one of the traditional IETF April Fools' jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. The RFC specifies this code should be returned by teapots requested to brew coffee.[19] This HTTP status is used as an Easter egg in some websites, such as Google.com's "I'm a teapot" easter egg.[20][21][22] Sometimes, this status code is also used as a response to a blocked request, instead of the more appropriate 403 Forbidden.[23][24]
421 Misdirected Request
The request was directed at a server that is not able to produce a response (for example because of connection reuse).
422 Unprocessable Content
The request was well-formed (i.e., syntactically correct) but could not be processed.[1]: §15.5.21 
423 Locked (WebDAV; RFC 4918)
The resource that is being accessed is locked.[7]
424 Failed Dependency (WebDAV; RFC 4918)
The request failed because it depended on another request and that request failed (e.g., a PROPPATCH).[7]
425 Too Early (RFC 8470)
Indicates that the server is unwilling to risk processing a request that might be replayed.
426 Upgrade Required
The client should switch to a different protocol such as TLS/1.3, given in the Upgrade header field.
428 Precondition Required (RFC 6585)
The origin server requires the request to be conditional. Intended to prevent the 'lost update' problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.[25]
429 Too Many Requests (RFC 6585)
The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.[25]
431 Request Header Fields Too Large (RFC 6585)
The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large.[25]
451 Unavailable For Legal Reasons (RFC 7725)
A server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource.[26] The code 451 was chosen as a reference to the novel Fahrenheit 451.[27]

5xx server errors

[edit]

The server failed to fulfill a request.

Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method.

500 Internal Server Error
A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.
501 Not Implemented
The server either does not recognize the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API).
502 Bad Gateway
The server was acting as a gateway or proxy and received an invalid response from the upstream server.
503 Service Unavailable
The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.[28]
504 Gateway Timeout
The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
505 HTTP Version Not Supported
The server does not support the HTTP version used in the request.
506 Variant Also Negotiates (RFC 2295)
Transparent content negotiation for the request results in a circular reference.[29]
507 Insufficient Storage (WebDAV; RFC 4918)
The server is unable to store the representation needed to complete the request.[7]
508 Loop Detected (WebDAV; RFC 5842)
The server detected an infinite loop while processing the request (sent instead of 208 Already Reported).
510 Not Extended (RFC 2774)
Further extensions to the request are required for the server to fulfil it.[30]
511 Network Authentication Required (RFC 6585)
The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g., "captive portals" used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot).[25]

Nonstandard codes

[edit]

The following codes are not specified by any standard.

218 This is fine (Apache HTTP Server)
Used by Apache servers. A catch-all error condition allowing the passage of message bodies through the server when the ProxyErrorOverride setting is enabled. It is displayed in this situation instead of a 4xx or 5xx error message.[31]
419 Page Expired (Laravel Framework)
Used by the Laravel Framework when a CSRF Token is missing or expired.[32]
420 Method Failure (Spring Framework)
A deprecated response status proposed during the development of WebDAV[33] used by the Spring Framework when a method has failed.[34]
420 Enhance Your Calm (Twitter)
Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.[35] The phrase "Enhance your calm" comes from the 1993 movie Demolition Man, and its association with this number is likely a reference to cannabis.[citation needed]
430 Request Header Fields Too Large (Shopify)
A deprecated response used by Shopify, instead of the 429 Too Many Requests response code, when too many URLs are requested within a certain time frame.[36]
430 Shopify Security Rejection (Shopify)
Used by Shopify to signal that the request was deemed malicious.[37]
450 Blocked by Windows Parental Controls (Microsoft)
The Microsoft extension code indicated when Windows Parental Controls are turned on and are blocking access to the requested webpage.[38]
498 Invalid Token (Esri)
Returned by ArcGIS Server. Code 498 indicates an expired or otherwise invalid token.[39]
499 Token Required (Esri)
Returned by ArcGIS Server. Code 499 indicates that a token is required but was not submitted.[39]
508 Resource Limit Is Reached (cPanel)
Used instead of 503 when the server's account has exceeded the resources assigned to it, such as CPU/RAM usage or number of concurrent processes.[40]
509 Bandwidth Limit Exceeded (Apache Web Server/cPanel)
The server has exceeded the bandwidth specified by the server administrator; this is often used by shared hosting providers to limit the bandwidth of customers.[41]
525 SSL handshake failed (Cloudflare)
This error indicates that the SSL handshake between Cloudflare and the origin web server failed.[42]
526 Invalid SSL certificate (Cloudflare)
This error indicates that Cloudflare is unable to verify the SSL certificate on the origin server, preventing a secure connection from being established.[43]
529 Site is overloaded
Used by Qualys in the SSLLabs server testing API to signal that the site can not process the request.[44]
530 Site is frozen
Used by the Pantheon Systems web platform to indicate a site that has been frozen due to inactivity.[45]
530 Origin DNS Error (Shopify)
Used by Shopify to indicate that Cloudflare can't resolve the requested DNS record.[37]
530 Origin Unavailable (Cloudflare)
Used by Cloudflare to indicate that it is unable to resolve the origin hostname, preventing it from establishing a connection to the origin server.[46]
540 Temporarily Disabled (Shopify)
Used by Shopify to indicate that the requested endpoint has been temporarily disabled.[37]
598 (Informal convention) Network read timeout error
Used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.[47]
599 Network Connect Timeout Error
An error used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.
783 Unexpected Token (Shopify)
Used by Shopify to indicate that the request includes a JSON syntax error.[37]
999 Non-standard
Error 999 is used by LinkedIn and is related to being blocked/walled or unable to access their webpages without first signing in.[48]

Internet Information Services

[edit]

Microsoft's Internet Information Services (IIS) web server expands the 4xx error space to signal errors with the client's request.

440 Login Time-out
The client's session has expired and must log in again.[49]
449 Retry With
The server cannot honour the request because the user has not provided the required information.[50]
451 Redirect
Used in Exchange ActiveSync when either a more efficient server is available or the server cannot access the users' mailbox.[51] The client is expected to re-run the HTTP AutoDiscover operation to find a more appropriate server.[52]

IIS sometimes uses additional decimal sub-codes for more specific information,[53] however these sub-codes only appear in the response payload and in documentation, not in the place of an actual HTTP status code.

nginx

[edit]

The nginx web server software expands the 4xx error space to signal issues with the client's request.[54][55]

444 No Response
Used internally[56] to instruct the server to return no information to the client and close the connection immediately.
494 Request header too large
Client sent too large request or too long header line.
495 SSL Certificate Error
An expansion of the 400 Bad Request response code, used when the client has provided an invalid client certificate.
496 SSL Certificate Required
An expansion of the 400 Bad Request response code, used when a client certificate is required but not provided.
497 HTTP Request Sent to HTTPS Port
An expansion of the 400 Bad Request response code, used when the client has made a HTTP request to a port listening for HTTPS requests.
499 Client Closed Request
Used when the client has closed the request before the server could send a response.

Cloudflare

[edit]

Cloudflare's reverse proxy service expands the 5xx series of errors space to signal issues with the origin server.[57]

520 Web Server Returned an Unknown Error
The origin server returned an empty, unknown, or unexpected response to Cloudflare.[58]
521 Web Server Is Down
The origin server refused connections from Cloudflare. Security solutions at the origin may be blocking legitimate connections from certain Cloudflare IP addresses.[59]
522 Connection Timed Out
Cloudflare timed out contacting the origin server.[60]
523 Origin Is Unreachable
Cloudflare could not contact the origin server.[61]
524 A Timeout Occurred
Cloudflare was able to complete a TCP connection to the origin server, but the origin did not provide a timely HTTP response.[62]
525 SSL Handshake Failed
Cloudflare could not negotiate a SSL/TLS handshake with the origin server.[63]
526 Invalid SSL Certificate
Cloudflare could not validate the SSL certificate on the origin web server.[64] Also used by Cloud Foundry's gorouter.
527 Railgun Error (obsolete)
Error 527 indicated an interrupted connection between Cloudflare and the origin server's Railgun server.[65] This error is obsolete as Cloudflare has deprecated Railgun.
530
Cloudflare was unable to resolve the origin hostname, preventing it from establishing a connection to the origin server. The body of the response contains an 1xxx error.[66]

AWS Elastic Load Balancing

[edit]

Amazon Web Services' Elastic Load Balancing adds a few custom return codes to signal issues either with the client request or with the origin server.[67]

000
Returned with an HTTP/2 GOAWAY frame if the compressed length of any of the headers exceeds 8K bytes or if more than 10K requests are served through one connection.[67]
460
Client closed the connection with the load balancer before the idle timeout period elapsed. Typically, when client timeout is sooner than the Elastic Load Balancer's timeout.[67]
463
The load balancer received an X-Forwarded-For request header with more than 30 IP addresses.[67]
464
Incompatible protocol versions between Client and Origin server.[67]
561 Unauthorized
An error around authentication returned by a server registered with a load balancer. A listener rule is configured to authenticate users, but the identity provider (IdP) returned an error code when authenticating the user.[67]

Caching warning codes (obsoleted)

[edit]

The following caching related warning codes were specified under RFC 7234. Unlike the other status codes above, these were not sent as the response status in the HTTP protocol, but as part of the "Warning" HTTP header.[68][69]

Since this "Warning" header is often neither sent by servers nor acknowledged by clients, this header and its codes were obsoleted by the HTTP Working Group in 2022 with RFC 9111.[70]

110 Response is Stale
The response provided by a cache is stale (the content's age exceeds a maximum age set by a Cache-Control header or heuristically chosen lifetime).
111 Revalidation Failed
The cache was unable to validate the response, due to an inability to reach the origin server.
112 Disconnected Operation
The cache is intentionally disconnected from the rest of the network.
113 Heuristic Expiration
The cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 hours.
199 Miscellaneous Warning
Arbitrary, non-specific warning. The warning text may be logged or presented to the user.
214 Transformation Applied
Added by a proxy if it applies any transformation to the representation, such as changing the content encoding, media type or the like.
299 Miscellaneous Persistent Warning
Same as 199, but indicating a persistent warning.

See also

[edit]

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

List of HTTP status codes

View on Grokipedia
from Grokipedia
HTTP status codes are standardized three-digit integers returned by a in response to a client's HTTP request, conveying the outcome of the request's processing and indicating whether it succeeded, requires further action, or encountered an error. These codes, first defined in the HTTP/1.0 specification and refined in subsequent versions, form a key part of the Hypertext Transfer Protocol (HTTP), enabling clear communication between clients (such as web browsers) and servers about the request's status. The codes are grouped into five classes based on the first digit, each representing a broad category of responses: 1xx for informational messages signaling that the request is being processed; 2xx for successful outcomes, such as the request being received and fulfilled; 3xx for redirection, prompting the client to take additional steps like following a new URI; 4xx for client errors, where the request contains invalid syntax or cannot be fulfilled due to client-side issues; and 5xx for server errors, indicating that the server failed to handle a valid request. As of September 2025, the (IANA) maintains a registry of 54 officially assigned HTTP status codes, ranging from 100 to 511, with many additional codes left unassigned for future use or extensions via separate RFCs like RFC 6585, which introduces codes such as 428 (Precondition Required) and 429 (Too Many Requests). This list ensures interoperability across HTTP versions (1.1, 2, and 3) and is essential for developers, as each code pairs with a human-readable reason phrase (e.g., "200 OK") to provide precise feedback on web transactions.

Introduction

Definition and Purpose

HTTP status codes are three-digit integers returned by servers in response to client requests within the Hypertext Transfer Protocol (HTTP), serving as a mechanism to indicate the outcome of the request's processing on the server side. These codes enable servers to communicate concise, standardized feedback to clients, such as web browsers or API consumers, about whether a request succeeded, failed, requires further action, or encountered an error. The primary purpose of HTTP status codes is to provide machine-readable indicators that allow clients to interpret responses programmatically and take appropriate actions, such as retrying a request upon transient failure, following a redirect to a new resource, or displaying an error message to the user. This feedback loop is essential for the stateless nature of HTTP, ensuring reliable and efficient web communication without relying on verbose textual explanations. For instance, a client might automatically handle a temporary server overload by rescheduling the request, thereby improving overall system resilience. Historically, HTTP status codes were first formalized in HTTP/1.0 as outlined in RFC 1945, published by the (IETF) in May 1996, which introduced a basic set of codes to support early web interactions. The framework evolved significantly with HTTP/1.1 in RFC 9110 (June 2022), which refined and expanded the semantics while maintaining backward compatibility, and has been preserved in subsequent versions including (RFC 7540, May 2015) and (RFC 9114, June 2022), adapting to modern transport protocols like without altering the core status code system. The IANA maintains the official registry of these codes, ensuring global consistency and preventing conflicts in assignments. Standardized by the IETF through its (RFC) series, HTTP status codes number 63 in the official registry as of September 2025, reflecting ongoing refinements to address emerging web needs while preserving interoperability. These codes are classified into five categories based on their first digit—1xx for informational, 2xx for success, 3xx for redirection, 4xx for client errors, and 5xx for server errors—facilitating quick interpretation by both humans and machines.

Format and Classification

HTTP status codes are structured as three-digit integers, denoted in the format ABC, where the first digit A represents the response class (ranging from 1 to 5), the second digit B indicates a subcategory within that class, and the third digit C provides additional specificity to the status. These codes are transmitted by servers in the response's Status-Line header field, formatted as "HTTP/version status-code SP reason-phrase", such as "HTTP/1.1 ", where the version specifies the HTTP protocol version, the status code is the three-digit value, and the reason-phrase is an optional human-readable description. The classification system organizes these codes into five primary classes based on the first digit, ensuring predictable behavior for clients across different HTTP implementations: 1xx codes denote informational or provisional responses, indicating that the request is being processed; 2xx codes signal successful completion of the client's request; 3xx codes represent redirection, prompting the client to take further action; 4xx codes indicate client errors, such as malformed requests or unauthorized access; and 5xx codes signify server errors, where the server failed to fulfill a valid request. The HTTP specifications define five classes of status codes (1xx to 5xx); no 0xx or 6xx classes are defined to maintain compatibility with the established . Registration of HTTP status codes is managed through the (IANA), which maintains the official Hypertext Transfer Protocol (HTTP) Status Code Registry to prevent conflicts and ensure standardization. Provisional or experimental codes require review by the (IETF) before temporary assignment, while permanent codes must be defined in a Standards Track (RFC) document approved by the IETF to guarantee interoperability. As of November 2025, the IANA registry lists over 60 registered status codes, with the class-based system promoting consistent handling and interpretation across HTTP versions from 1.0 to 3.0.

Standard Status Codes

1xx: Informational Responses

The 1xx status codes are informational responses that provide provisional feedback to the client, indicating that the server has received the request and is continuing to process it without yet providing a final outcome. These codes facilitate efficient communication, particularly in scenarios involving large payloads or protocol negotiations, by allowing clients to confirm server readiness before proceeding with resource-intensive actions. Unlike final status codes, 1xx responses do not complete the request; clients must await a subsequent final response to determine success or failure. 100 Continue
The 100 Continue status code signals that the server has received the request headers and has not rejected them, prompting the client to send the request body if it has not already done so. This mechanism is especially valuable for requests with large bodies, such as file uploads, where the client includes an Expect: 100-continue header to query server acceptance before transmitting the , thereby avoiding unnecessary bandwidth usage if the request would otherwise be denied (e.g., due to issues). Servers must respond promptly with 100 Continue if the headers are valid and a body is expected, though this does not guarantee ultimate acceptance of the full request. 101 Switching Protocols
The 101 Switching Protocols status code indicates that the server agrees to the client's request to upgrade the protocol, as specified in the Upgrade request header, enabling a seamless transition on the existing connection. For instance, this is commonly used to switch from HTTP/1.1 to for real-time bidirectional communication, where the client sends Upgrade: websocket and the server confirms with Upgrade: websocket in its 101 response, after which the connection adopts the new protocol. The upgrade applies only to the current connection and requires the server to honor the requested protocol if it responds affirmatively. 102 Processing
Introduced for WebDAV extensions, the 102 Processing status code informs the client that the server has accepted the request and is actively processing it, though a final response is not yet available. This is particularly useful for lengthy operations, such as those involving resource locking or depth-limited queries in distributed authoring environments, where it prevents premature client timeouts by signaling ongoing activity (e.g., for requests expected to exceed 20 seconds). The server must eventually send a final status code upon completion, and clients should not interpret 102 as an indication of imminent success. 103 Early Hints
The 103 Early Hints status code allows the server to send preliminary header fields to the client before the final response, enabling optimizations such as resource preloading to reduce perceived latency. For example, a server might include Link headers with rel=preload directives (e.g., Link: </style.css>; rel=preload; as=style) to prompt the client to fetch critical assets like stylesheets or scripts in advance. Multiple 103 responses may be sent with evolving headers, but clients should treat them speculatively and discard any hints that conflict with the eventual final response. 104 Upload Resumption Supported
As a provisional status code, 104 Upload Resumption Supported indicates that the server can handle resumable , typically sent during the initial creation of an to inform the client of this capability via a Location header pointing to the endpoint. This enables clients to resume interrupted transfers by querying the current offset (e.g., via Upload-Offset in subsequent responses) and appending the remaining data, which is beneficial for unreliable networks or large files prone to disruptions. Registered temporarily on November 13, 2024, extended on September 15, 2025, with an expiration on November 13, 2026, its use is optional and tied to emerging HTTP extensions for robust handling. In practice, 1xx responses are infrequently used outside specialized contexts like long-running requests or protocol upgrades, as most HTTP interactions complete without interim signaling; clients must not assume request completion based on a 1xx code alone and should always await the final response.

2xx: Successful Responses

The 2xx class of status codes indicates that a client's request was successfully received, understood, and accepted by the server, signifying the completion of the requested action without errors. These responses confirm successful outcomes for various HTTP methods, such as retrieving, creating, or modifying resources, and they often include representation data or metadata in the unless specified otherwise. Caching directives, such as those defined in related standards, frequently apply to 2xx responses to optimize performance and reduce unnecessary requests. The specific codes within this range provide nuanced feedback on the nature of the success:
CodeNameDescription
200OKThis status code signifies that the request has succeeded, with the response typically enclosing a representation of the target resource or results of the action, depending on the method (e.g., full content for GET requests). For methods like PUT or DELETE, the payload may include status information, an updated resource representation, or details about the completed operation. It is commonly used for successful reports or status inquiries, such as OPTIONS requests.
201CreatedReturned when a request (e.g., POST or PUT) has been fulfilled by creating one or more new resources, often accompanied by a Location header field identifying the primary resource's URI. The response payload usually describes or embeds the new resource(s), and an ETag header may indicate the entity's current tag; caches must not store the response without appropriate validators to prevent sharing unintended resources.
202AcceptedThis code indicates that the request has been accepted for processing, but the action is not yet complete—suitable for asynchronous operations like batch jobs. The response may include a representation describing the current status and possibly linking to a monitor for progress updates, without committing to eventual fulfillment.
203Non-Authoritative InformationUsed by proxies or gateways to signal successful processing where the response payload has been modified from the origin server's original (e.g., transformations applied), ensuring clients understand potential differences in the data. Origin servers must not generate this code, and it remains cacheable unless overridden by method or cache controls.
204No ContentIndicates successful fulfillment of the request with no additional content in the response body, often for updates like PUT or DELETE where metadata (e.g., ETag for the updated resource) suffices. The response ends immediately after headers and is cacheable by default, referring to the target resource's post-action state. It is commonly used for tracking endpoints, such as invisible links or beacons in analytics systems (e.g., Google Analytics), where the server logs the request (e.g., a click) without returning any content to the client.
205Reset ContentSignals successful request fulfillment and instructs the user agent to reset the document view (e.g., clearing a form) to its original or default state, supporting data entry scenarios without sending a response body. This code terminates after the headers and is rarely used in modern applications.
206Partial ContentDenotes successful delivery of a partial representation of the target resource in response to a range request (e.g., byte-range for resumable downloads), requiring a Content-Range header to specify the included portions. The payload must not exceed the requested ranges, and invalid ranges trigger a 416 error instead. Defined in RFC 7233 and integrated into core semantics.
207Multi-StatusThe 207 Multi-Status status code provides status for multiple independent operations, typically in WebDAV contexts where a single request affects multiple resources; the response body is an XML message containing separate status codes for each operation.
208Already ReportedUsed within a 207 Multi-Status response in WebDAV to indicate that the members of a DAV binding have already been enumerated in a previous reply, avoiding duplication and potential XML element conflicts.
226IM UsedIndicates that 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, using delta encoding to fulfill the request.

3xx: Redirection Messages

The 3xx class of HTTP status codes indicates that further action is required by the client to complete the request, typically involving redirection to a different URI provided in the response. These codes facilitate resource relocation without implying an error, distinguishing them from 2xx successful responses, which deliver the requested content directly, and from 4xx client errors, which signal invalid requests. Clients are generally expected to follow these redirects automatically, but implementations must limit the number of redirections to prevent infinite loops, often capping at around 5-10 iterations depending on the . Most 3xx responses (except 304) require a Location header field containing the target URI, which may be absolute or relative. 300 Multiple Choices signals that the requested resource has multiple representations or equivalents, such as different formats or languages, and the client or user must select one. The server may include a Location header suggesting a preferred choice, but the response body can list options for user selection, often used in content negotiation scenarios. Unlike other redirects, this code does not imply relocation but rather choice among alternatives. 301 Moved Permanently indicates that the resource has been assigned a new permanent URI, and clients should update references, such as bookmarks or caches, to use the new location for all future requests. The Location header provides the new URI, and user agents with editing capabilities are expected to automatically adjust links. This code allows the original request method to change to GET if it was POST, though modern practices recommend preserving methods where possible. 302 Found, also known as Moved Temporarily in some contexts, denotes that the resource is temporarily available at a different URI, but the original URI should remain the preferred reference for future requests. It requires a Location header, and like 301, it may result in changing a method to GET upon redirection, which can lead to unintended in form submissions. This status is commonly used for short-term redirects, such as maintenance pages. 303 See Other directs the client to retrieve the response from a different URI, typically after a state-changing operation like , to prevent accidental resubmission of the request upon refresh. The Location header specifies the URI, and clients must follow it with a GET method, regardless of the original request method; the response body from the 303 itself is not forwarded. This code ensures safe navigation post-submission without implying any movement of the original resource. 304 Not Modified responds to a conditional request (using headers like If-Modified-Since or If-None-Match) when the resource has not changed since the specified date or entity tag, allowing the client to use its cached version without sending the body. No Location header is required, and the response includes relevant cache-control headers to maintain consistency. This code optimizes bandwidth by leveraging caching mechanisms outlined in successful response handling. 305 Use Proxy indicates that the requested resource must be accessed through the proxy given by the Location field; it is deprecated and rarely used due to security concerns with non-HTTPS proxies. 306 (Unused) was originally defined for subsequent requests to use the specified proxy but is no longer used and must not be sent. 307 Temporary Redirect behaves like 302 but mandates that the client preserve the original request method and body when following the redirect, making it safer for non-GET requests like POST. The Location header provides the temporary URI, and clients must not change the method, ensuring idempotence where applicable. Introduced to address ambiguities in earlier temporary redirects, it is widely supported in modern user agents. 308 Permanent Redirect, defined in RFC 7238, mirrors 301 but requires preservation of the original request method and body, preventing unintended method changes during permanent relocations. The Location header specifies the new permanent URI, and clients should update future references accordingly while maintaining the request semantics. This code ensures reliable handling of non-GET methods in permanent scenarios, such as API endpoint migrations.

4xx: Client Errors

The 4xx class of status codes indicates that the client seems to have made an error in its request, such as bad syntax, invalid parameters, or authentication issues, preventing the server from processing it. These codes signal problems originating from the client side, in contrast to 5xx server errors that reflect server-side failures. Unlike 3xx redirection messages, which instruct the client to follow a new URI for the resource, 4xx codes require the client to correct the request before retrying, as automatic resubmission without modification may result in persistent failure. Servers sending 4xx responses should include a descriptive reason phrase and may provide additional details in the response body, though clients must not rely on specific formats beyond the code itself. Common resolutions involve inspecting request syntax, headers, and body for errors, then resending a corrected version; for example, validating JSON payloads or adding missing authentication credentials. The following enumerates the standard 4xx codes, including their definitions, typical causes, associated headers, and guidance for resolution.
CodeDescriptionCommon CausesRelevant HeadersResolution
400 Bad RequestThe server cannot or will not process the request due to a perceived client error, such as malformed syntax or invalid message framing.Invalid parameters, like malformed JSON in the request body, or deceptive request routing.None specified.Examine and correct request syntax or parameters, such as ensuring valid JSON structure, then retry.
401 UnauthorizedThe request lacks valid authentication credentials for the target resource, requiring the client to authenticate.Missing or invalid credentials, such as an absent or expired token.WWW-Authenticate (indicates authentication schemes and parameters).Provide valid credentials via the specified scheme (e.g., Basic or Bearer) and retry.
402 Payment RequiredReserved for future use, potentially for scenarios like digital payment requirements in APIs.Not currently defined or implemented in practice; rarely used.None specified.Implement payment or subscription as per service requirements, though actual usage remains limited.
403 ForbiddenThe server understands the request but refuses to authorize it, often due to insufficient permissions.Access denied despite valid authentication, such as role-based restrictions.None specified.Verify and elevate user permissions or contact the resource owner; do not retry without changes.
404 Not FoundThe origin server did not find a current representation for the target resource at the given URI.The resource does not exist, has been moved without redirection, or the URI is incorrect.None specified.Check the URI for typos or confirm resource availability; consider alternatives like search endpoints.
405 Method Not AllowedThe method specified in the request is known by the server but not supported for the target resource.Attempting an unsupported HTTP method, such as PUT on a read-only resource.Allow (lists supported methods).Switch to an allowed method from the Allow header and retry.
406 Not AcceptableThe target resource lacks a representation that conforms to the client's specified preferences.Mismatch in Accept headers, such as requesting an unsupported content type or language.Vary (indicates varying factors like Accept).Adjust Accept headers to match available representations or broaden preferences, then retry.
407 Proxy Authentication RequiredThe client must first authenticate itself with the proxy server.Missing or invalid proxy credentials in a proxied environment.Proxy-Authenticate (authentication schemes for proxy); Proxy-Authorization (client credentials).Supply proxy credentials via Proxy-Authorization and retry.
408 Request TimeoutThe server timed out waiting for the complete request message from the client.The client took too long to send the request, often due to network delays or large payloads.None specified.Reduce request size, improve connection speed, or resend promptly.
409 ConflictThe request could not be completed due to a conflict with the current state of the target resource.State mismatch, such as version conflicts during concurrent updates.None specified.Resolve the conflict by updating based on the current resource state (e.g., via ETag) and retry.
410 GoneAccess to the target resource is no longer available at the origin server and this condition is permanent.The resource has been permanently deleted or archived with no forwarding address.None specified.Cease requests to this URI; seek an alternative resource or archive.
411 Length RequiredThe server refuses to accept the request without a defined Content-Length header.Missing Content-Length for methods expecting a body, like POST.Content-Length (required for body size).Include a valid Content-Length header matching the body size and retry.
412 Precondition FailedOne or more conditions given in the request header fields evaluated to false when tested on the server.Preconditions like If-Match or If-Unmodified-Since not satisfied, often in optimistic concurrency.ETag, If-Match (for entity validation).Update preconditions with current resource metadata (e.g., fresh ETag) and retry.
413 Content Too LargeThe server refuses to process the request because the request payload exceeds what it is willing or able to handle (formerly known as Payload Too Large).Request body size surpasses server limits, such as upload quotas.Content-Length (indicates oversized payload).Reduce the payload size or split into multiple requests, then retry.
414 URI Too LongThe server refuses to service the request because the target URI is longer than it is willing to interpret.Excessively long URI, often from nested query parameters.None specified.Shorten the URI by simplifying queries or using POST for data, then retry.
415 Unsupported Media TypeThe origin server refuses to service the request because the payload is in a format not supported by the target resource for the requested method.Incompatible Content-Type, such as sending XML to a JSON-only endpoint.Content-Type (request body format); Accept (preferred formats).Change the payload to a supported media type per Accept and retry.
416 Range Not SatisfiableThe range specified in the request cannot be fulfilled, such as due to invalid byte ranges.Requested range exceeds resource boundaries or is malformed.Range (request range); Content-Range (response details).Adjust the Range header to valid bounds based on Content-Range and retry.
417 Expectation FailedThe server refuses the request because the expectation in the Expect header field cannot be met by the server.Unsupported Expect value, such as 100-continue when the server does not support it.Expect (client expectations).Remove or modify the Expect header to a supported value and retry.
421 Misdirected RequestThe request was directed at a server unable to produce a response, such as after a misrouted redirect.Sent to the wrong server instance, common in HTTP/2 multiplexing or load balancing errors.None specified.Redirect to the correct server or verify routing configuration, then retry.
422 Unprocessable ContentThe server understands the content type and syntax of the request entity but cannot process the contained instructions (from WebDAV, standardized in RFC 9110).Semantic errors in the body, such as valid JSON with invalid business logic values.None specified.Correct semantic issues in the payload, like validation rules, and retry.
423 LockedThe source or destination resource of the method is locked (from WebDAV, RFC 4918).Attempting to modify a locked resource without the required lock token.If (with lock token).Obtain and include the lock token via the If header, or wait for unlock, then retry.
424 Failed DependencyThe method could not be performed on the resource because the requested action depended on another action that failed (from WebDAV, RFC 4918).A dependent operation, like a multi-step update, failed earlier in the sequence.None specified.Address the underlying dependency failure and resubmit the full request.
425 Too EarlyThe server is unwilling to process the request due to risks like replay attacks from early data (RFC 8470).Use of early data in TLS 1.3 before full handshake, posing security risks.Early-Data (indicates early data usage).Complete the TLS handshake fully before sending the request and retry.
426 Upgrade RequiredThe server refuses the request using the current protocol but may succeed after the client upgrades.Outdated protocol version incompatible with the resource.Upgrade (specifies required protocol).Upgrade to the protocol in the Upgrade header (e.g., from HTTP/1.1 to HTTP/2) and retry.
428 Precondition RequiredThe origin server requires the request to be conditional to prevent lost updates (RFC 6585).Missing conditional headers during concurrent resource modifications.If-Match (suggested for conditionals).Add appropriate precondition headers like If-Match with current ETag and retry.
429 Too Many RequestsThe user has sent too many requests in a given time period, indicating rate limiting (RFC 6585).Exceeding API quotas or throttling thresholds based on IP or credentials.Retry-After (delay before retry).Wait the duration specified in Retry-After and reduce request frequency before retrying.
431 Request Header Fields Too LargeThe server is unwilling to process the request because its header fields are too large (RFC 6585).Excessive total header size or a single oversized header, like large cookies.None specified.Trim unnecessary headers or compress values, then retry.
451 Unavailable For Legal ReasonsThe server is denying access to the resource due to legal demands or restrictions (RFC 7725).Content blocked by court order, censorship, or regulatory compliance.Link (with rel="blocked-by" to the legal entity).Do not retry; seek legal alternatives or contact the blocking authority.
In general, clients encountering 4xx errors should not attempt automatic recovery without user intervention or request modification, as these codes attribute fault to the client and indicate no server-side issue.

5xx: Server Errors

The 5xx class of HTTP status codes indicates that the server is aware that it has erred or is incapable of performing the requested method, despite the request appearing valid from the client's perspective. These codes apply to any request method and distinguish server-side issues from client errors (4xx), emphasizing that the fault lies with the server and not requiring client-side corrections. Many 5xx responses are transient, such as those arising from temporary overloads or upstream failures in proxies and load balancers, and clients are generally advised to retry the request with to avoid exacerbating the issue. However, not all 5xx errors warrant retries; permanent limitations, like unsupported features, do not resolve through repetition.
CodeDescriptionCommon Causes and ExamplesRetry Guidance
500 Internal Server ErrorA generic response for an unexpected server condition that prevents fulfilling the request, serving as a catch-all when no other 5xx code applies.Often due to unhandled exceptions, scripting errors, or internal misconfigurations, such as a database failure or application crash.Clients may retry after a short delay if the error is likely temporary, using exponential backoff to respect server load.
501 Not ImplementedIndicates that the server does not recognize or support the functionality needed to process the request, such as an unrecognized method.Typically occurs when a client uses a new or unsupported HTTP method (e.g., an experimental method like PATCH on a server limited to GET and POST) or an unavailable feature.Retries are not recommended, as the server lacks the capability; clients should use an alternative method or endpoint.
502 Bad GatewaySignals that a server acting as a gateway or proxy received an invalid or erroneous response from an upstream server while attempting to fulfill the request.Common in load-balanced environments where the upstream server (e.g., an application server) returns malformed data, crashes, or is misconfigured.Clients may retry after a delay, as the issue could be transient; exponential backoff is advised to prevent overload.
503 Service UnavailableDenotes that the server is temporarily unable to handle the request due to overload or maintenance, indicating a server-side issue not specific to the client's system, browser, or network (though client-side firewalls or ISP restrictions on non-standard ports may sometimes contribute to access issues), with the condition expected to resolve after a delay.Arises from high traffic causing overload, scheduled maintenance, or resource exhaustion, such as exceeding concurrent request limits in an application pool. The response may include a Retry-After header specifying the wait time.Retries are recommended after the indicated delay or with backoff; this is a standard signal for temporary unavailability.
504 Gateway TimeoutIndicates that a server acting as a gateway or proxy did not receive a timely response from an upstream server required to complete the request.Occurs in proxy setups when the upstream server (e.g., in a load balancer chain) times out due to slow processing, network delays, or unresponsiveness.Clients may retry after a delay if the upstream issue is transient; backoff strategies help mitigate repeated failures.
505 HTTP Version Not SupportedMeans the server does not support or refuses the major HTTP protocol version used in the request.Triggered when a client sends a request with an incompatible version, such as HTTP/2 to a server limited to HTTP/1.1.Retries are ineffective; clients must downgrade to a supported version or use a compatible protocol.
506 Variant Also NegotiatesTransparent content negotiation results in a circular reference, indicating an internal server configuration error where a negotiating resource refers to itself.Misconfigured content negotiation leading to loops in variant selection.Retries unlikely to help; server configuration must be corrected by administrators.
507 Insufficient StorageThe server is unable to store the representation needed to successfully complete the request, often due to insufficient space (from WebDAV, RFC 4918).Disk quota exceeded or storage limits reached during upload or creation operations.Free up storage or request more quota; retry after resolution.
508 Loop DetectedThe server detected an infinite loop while processing the request, terminating the operation (from WebDAV, RFC 5842).Circular references in resource bindings or depth-infinity PROPFIND requests.Retries not recommended without fixing the loop in server configuration or request.
511 Network Authentication RequiredThe client needs to authenticate to gain network access, typically from a captive portal (RFC 6585).Accessing a network without prior authentication, such as in public Wi-Fi hotspots.Complete the authentication process in the browser or client as prompted.
In general, 5xx errors highlight server responsibility, and robust clients implement automatic retries with increasing intervals for codes like 500, 502, 503, and 504 to improve resilience without assuming client fault. Gateway-related 5xx codes (502 and 504) frequently appear in distributed systems involving load balancers, where upstream dependencies introduce points of .

Extension Codes

WebDAV and Protocol Extensions

WebDAV (Web Distributed Authoring and Versioning) introduces several HTTP status code extensions to support collaborative web content management, file locking, and batch operations on distributed resources. These codes build upon core HTTP semantics, particularly in the 2xx and 4xx ranges, to handle scenarios like partial successes and resource conflicts in protocols that enable authoring over HTTP. Defined in RFC 4918, WebDAV extensions are standardized for interoperability and require explicit server support, typically advertised via the "DAV" header. They facilitate operations such as property manipulation and collection handling without relying on vendor-specific implementations. The 207 Multi-Status code indicates a response containing status information for multiple independent operations, allowing servers to report partial successes or failures in a single message. It is commonly used in methods like PROPFIND, where a request on a collection returns results for multiple resources; for instance, the response body uses an XML "multistatus" element with individual "response" elements, each specifying an href (resource ) and propstat (property status, such as 200 OK or 404 Not Found). This structure, with Content-Type: application/xml, enables efficient handling of hierarchical queries without multiple round trips. The 208 Already Reported code, an extension for bindings, prevents redundant enumeration of collection members in multi-status responses. It appears in DAV:propstat elements to signal that internal members of multiple bindings to the same collection have already been reported elsewhere, avoiding duplicates during "Depth: " PROPFIND requests that could otherwise cause loops. For example, only the first ing reports a status with full details, while subsequent ones use 208 and omit descendant listings, requiring client support via the "bind" token in the DAV header. In the 4xx client error range, WebDAV defines codes for validation and dependency issues. The 422 Unprocessable Entity code signifies that the server understands the request's content type and syntax but cannot process it due to semantic errors, such as invalid XML in a PROPPATCH operation. It differs from Bad Request by focusing on content semantics rather than syntax, providing a targeted indication for authoring failures. The 423 Locked code denotes that a resource involved in the request (source or destination) is locked, blocking the operation unless a valid lock token is submitted. This supports 's locking mechanism to prevent concurrent modifications; for example, a DELETE on a locked resource returns 423, often accompanied by a error like "lock-token-submitted." The 424 Failed Dependency code indicates that the requested action could not proceed because it depended on another action that failed, commonly in batch or multi-resource operations. In PROPPATCH, for instance, if removing one property fails with 409 Conflict, a subsequent property set might return 424 to highlight the cascade. This code aids in diagnosing chained errors within WebDAV's multistatus framework. Beyond core WebDAV, protocol extensions like delta encoding introduce the 226 IM Used code for efficient partial resource updates. It confirms that the server has applied one or more instance-manipulations (e.g., via the A-IM request header specifying "vcdiff") to the current resource instance, delivering a delta representation rather than the full entity. The response includes an IM header listing the manipulations and an ETag for the resulting instance, reducing bandwidth for incremental changes in HTTP/1.1.
CodeNameClassDescriptionRFC
207Multi-Status2xxStatus for multiple operations, e.g., in PROPFIND on collections.RFC 4918
208Already Reported2xxAvoids duplicate member reporting in WebDAV bindings.RFC 5842
422Unprocessable Entity4xxSemantic errors in well-formed requests, e.g., invalid PROPPATCH XML.RFC 4918
423Locked4xxResource locked; requires valid token for access.RFC 4918
424Failed Dependency4xxAction failed due to prior dependent failure in batch ops.RFC 4918
226IM Used2xxDelta encoding applied successfully for partial updates.RFC 3229

Provisional and Experimental Codes

Provisional and experimental HTTP status codes are those registered with the (IANA) on a temporary basis to support ongoing protocol development and testing, without full standardization. These codes allow implementers to experiment with new features in controlled environments, but they may be promoted to permanent status, modified, or withdrawn based on further review and adoption. IANA explicitly designates such codes as temporary in its registry, often tying them to specific Internet-Draft documents with defined expiration dates. As of November 2025, the number of provisional codes remains limited, reflecting the cautious approach to extending the HTTP status code space. One notable example is the 104 status code, titled "Upload Resumption Supported," which was registered as temporary on , 2024, with an extension to , 2025, and set to expire on , 2026. This code, defined in the Internet-Draft draft-ietf-httpbis-resumable-upload, enables servers to indicate support for resumable s by responding to a HEAD or OPTIONS request on an endpoint with the Upload-Offset header, specifying the current byte offset of the upload. It addresses challenges in modern networks prone to interruptions, such as mobile or unreliable connections, by allowing clients to resume large file uploads from the point of failure rather than restarting entirely, similar in spirit to informational responses like 100 Continue but tailored for upload scenarios.

Non-Standard Codes

Microsoft IIS Codes

Internet Information Services (IIS), the software developed by for Windows servers, incorporates proprietary substatus codes to augment standard HTTP status codes. These subcodes, formatted as a decimal extension to the three-digit code (e.g., 403.13), deliver enhanced diagnostic details for errors encountered during request processing. Primarily utilized in IIS logging for and performance analysis, they may also appear in HTTP responses when detailed error pages are configured, though they are not defined in the HTTP/1.1 specification or subsequent RFCs. This extension allows administrators to pinpoint issues related to configuration, security, and resource constraints more precisely than standard codes alone. Subcodes for the 400 Bad Request status elaborate on client-side request malformations, such as invalid headers or body content. Examples include 400.1 for an invalid Destination header in operations and 400.6 for an invalid request body, which can arise from malformed data. In IIS 8.0 and later, 400.10 addresses invalid headers used in load balancing scenarios, while 400.11 flags invalid requests. These subcodes span from 400.1 to approximately 400.12, with additional ARR (Application Request Routing) variants like 400.601 for bad client requests in proxy setups, aiding in identifying parsing failures without altering core HTTP semantics. The 403 Forbidden category features extensive subcodes detailing access denial reasons, from permission issues to certificate problems. Notable variants include 403.1 for execute access forbidden on scripts or executables, 403.13 for a revoked client certificate in SSL environments, and 403.16 for an untrusted or invalid client certificate. Other examples encompass 403.7 requiring a client certificate, 403.14 denying directory listings for , and 403.18 preventing URL execution outside the current application pool. Ranging from 403.1 to 403.22, with dynamic IP restriction extensions like 403.503 for denied IP addresses, these provide granular insights into and failures. For 404 Not Found responses, IIS subcodes specify the nature of the missing resource or request violation. Key instances are 404.15 for a exceeding length limits, 404.13 for content length too large, and 404.14 for the overall request being too long. Additional details cover 404.7 denying specific file extensions via restrictions, 404.5 blocked by request filtering rules, and 404.19 rejected due to a filtering rule match. These subcodes, from 404.0 to 404.20, including IP-based denials like 404.503, facilitate of resolution, filters, and size-based rejections. Internal server errors under 500 are broken down to isolate causes like configuration errors or exhaustion. Representative subcodes include 500.19 for invalid configuration data in web.config or applicationHost.config files, 500.13 indicating the is too busy to handle the request, and 500.11 signaling an application shutdown in progress. Others, such as 500.0 for a module or ISAPI error and 500.21 for an unrecognized module, range from 500.0 to 500.24, with rewrite module specifics like 500.50 for errors during request beginning. These help trace server-side faults, from busy states to misconfigurations. The 501 Not Implemented status in IIS is returned when request headers specify a server configuration or method not supported, such as unknown HTTP verbs beyond those in RFC 2616. While subcodes like 501.1 and 501.2 have been referenced in older IIS documentation for specific implementation gaps (e.g., unsupported CGI configurations), current versions primarily log the base 501 without routine substatus extensions. This code underscores IIS's adherence to defined protocols while highlighting custom or deprecated features.

nginx and Other Server Codes

Nginx, a popular open-source , introduces several non-standard HTTP status codes to handle specific conditions related to request processing and SSL/TLS interactions. These codes are not part of the IETF HTTP specifications but are used internally by to provide more granular reporting, often mapped to standard 4xx client s in responses to clients. They are particularly useful for debugging server-side issues involving oversized requests or SSL misconfigurations. The 494 status code indicates that the request header or is too large, exceeding the server's configured limits (e.g., via the large_client_header_buffers directive). Introduced in version 0.9.4, this code helps identify clients sending excessively long headers, which could be due to malicious activity or misconfigured applications, and it typically results in a 400 Bad Request response to the client unless customized via the error_page directive. In SSL/TLS contexts, uses 495 for errors during client certificate verification, such as invalid or untrusted certificates provided by the client. This code signals issues like certificate revocation problems or validation failures, often triggered when ssl_verify_client is enabled. Similarly, 496 is returned when a client fails to present a required SSL certificate during the , enforcing mandatory client in secure environments. The 497 code is specific to scenarios where a plain HTTP request is sent to an port, allowing the server to reject non-encrypted traffic on secure endpoints without fully processing the request. These SSL-related codes (495, 496, and 497) are documented in 's SSL module and can be intercepted and redirected using error pages for user-friendly responses. Other servers, such as , also employ non-standard codes in certain configurations, particularly for security features like (CSRF) protection. The 419 status code, often labeled "Page Expired," is used in Apache environments running frameworks like to indicate an expired or invalid session token, preventing unauthorized form submissions. This code is not native to Apache's core but arises from application-level handling of CSRF tokens, typically resulting in a client-side prompt to refresh the page and resubmit. These non-standard codes from and are primarily server-internal mechanisms for enhanced error handling, security enforcement, and configuration validation. They are often transparent to end-users, who receive standard 4xx or 5xx responses, but they aid administrators in and issues like violations (e.g., similar to 429 for too many requests) without exposing details.

CDN and Load Balancer Codes

Content Delivery Networks (CDNs) and load balancers, such as and AWS Elastic Load Balancing (ELB), extend the standard HTTP status codes with proprietary ones to provide more granular diagnostics for network and origin server issues. These codes are typically returned to clients when the intermediary service encounters problems communicating with the backend origin, often manifesting as infrastructure or connectivity failures rather than direct client or server errors. Unlike standard 5xx codes, these extensions help operators pinpoint distributed system challenges, such as timeouts or configuration mismatches, without altering the core HTTP protocol. They are non-standard and specific to the provider's ecosystem. Cloudflare uses a series of 52x codes to signal errors in its proxying of requests to origin servers. 520 indicates that the origin returned an empty, unknown, or unexpected response to Cloudflare, preventing proper interpretation of the reply; this often stems from malformed headers or server-side anomalies. 521 occurs when the origin refuses connections from Cloudflare, typically because the server is down or blocking Cloudflare's IP ranges. 522 occurs when Cloudflare cannot negotiate a TCP on the origin's port (after 19 seconds without +ACK) or when the origin does not acknowledge Cloudflare's resource request within 90 seconds after a connection is established, due to network latency or firewall restrictions. 523 means the origin is unreachable, often from DNS resolution failures or invalid IP configurations at the origin. 524 is triggered when a connection to the origin is established but no response is received within 120 seconds (default proxy read timeout), pointing to slow processing or resource exhaustion on the backend. 525 denotes a failed between Cloudflare and the origin, commonly caused by incompatible ciphers, expired certificates, or protocol mismatches. 526 is returned when the origin presents an invalid SSL certificate, such as one that is expired, revoked, or not matching the requested domain. AWS Application Load Balancer (ALB), part of Elastic Load Balancing, introduces 46x codes in access logs and responses to denote client-side or proxy-specific issues that affect request handling. Code 460 is issued when the client closes the connection to the load balancer before the configured idle timeout expires, often due to the client's shorter timeout settings or abrupt termination; the load balancer logs this but may not always propagate it directly to the client as a visible response. Code 463 occurs when the X-Forwarded-For header in the request contains more than 30 IP addresses, exceeding the load balancer's limit for tracking proxy chains and leading to request rejection. These codes complement standard gateway errors like 502 (Bad Gateway) and 504 (Gateway Timeout) by offering provider-specific insights into why the proxy failed to forward or receive responses from origins. In practice, these CDN and load balancer codes are invisible to end-users unless exposed in error pages, but they aid in debugging distributed architectures where standard 5xx codes provide insufficient detail on intermediary failures. Administrators should consult provider logs and metrics to correlate these with origin health, ensuring alignment between proxy timeouts and backend capabilities.

Obsoleted and Deprecated Codes

Caching Warning Codes

The Warning header was introduced in HTTP/1.1 as a general-header field to carry additional information about the status or transformation of a message that might not be reflected in the status code itself. It was particularly intended for use by caches to alert clients about potential issues with cached responses, such as staleness or failed validation, thereby promoting semantic transparency in caching operations. The header could appear multiple times in a response and followed a structured format: Warning = 1#warning-value, where each warning-value consisted of a three-digit warn-code, an agent identifier, human-readable warn-text, and an optional warn-date. Caching-related warnings were identified by 1xx warn-codes, which were generated exclusively by caches and intended for display to end users; these were to be deleted from the response after successful revalidation. The following table summarizes the standard 1xx caching warning codes defined in HTTP/1.1:
CodeDescription
110Response is stale: Indicates that the returned response is stale, and it must be included whenever a cache serves stale content.
111Revalidation failed: Signals that an attempt to revalidate a stale response failed, requiring inclusion when such a failure occurs.
112Disconnected operation: Warns that the cache is intentionally disconnected from the origin server, and it should be added for stale responses served in this state.
113 expiration: Applies when a cache uses heuristic freshness estimation that exceeds 24 hours and the response age surpasses 24 hours; it must be included in such cases.
199Miscellaneous warning: A catch-all for other cache-related warnings without automated client actions, intended for human-readable information.
These codes were part of a broader effort to handle cache validation, such as in responses related to the 304 Not Modified status, where warnings could indicate issues without altering the core caching directives. The Warning header and its associated 1xx caching warning codes were obsoleted in 2022 by RFC 9111, which defines the current HTTP caching semantics and deems the mechanism redundant since equivalent information can now be derived from other headers like Age. This obsolescence reflects the evolution toward stronger, more explicit caching controls, such as the must-revalidate directive, and the preference in and later versions for direct status codes over supplementary warnings. Even prior to deprecation, the Warning header was rarely used in practice, as implementations often relied on simpler freshness checks rather than generating or propagating these warnings. The IANA HTTP Warn Codes registry was updated accordingly to mark these codes as obsolete.

Unused and Reserved Codes

The (IANA) maintains the official registry of HTTP status codes to ensure standardized assignments and prevent conflicts in protocol implementations. Among these, certain codes are explicitly reserved or marked as unused, meaning they are not intended for current deployment in HTTP/1.1 or but are held for potential future standardization or to avoid reuse of deprecated semantics. As of September 2025, no new assignments have been made to these slots, reinforcing the recommendation to adhere to established standard codes for interoperability. Code 305 (Use Proxy) was originally defined to instruct clients to access the requested resource through a specified . However, it has been deprecated due to vulnerabilities, such as the risk of misleading clients into using untrusted proxies, and is no longer recommended for use; instead, the CONNECT method or code 307 (Temporary Redirect) should be employed for proxy-related redirections. This aligns with broader efforts to enhance HTTP by avoiding ambiguous proxy directives. Code 306, previously associated with proxy requirements similar to 305, is now fully unused and reserved solely to maintain the integrity of the 3xx redirection class without reintroducing obsolete proxy semantics. It serves no active role in modern HTTP implementations and is explicitly noted as such in the protocol specifications to discourage any adoption. In the 4xx client error range, code 402 ( Required) is reserved for potential future use in scenarios involving digital payment or subscription models, but it remains unimplemented in standard HTTP practice and lacks any defined semantics beyond this placeholder status. Servers are prohibited from generating this code outside of experimental contexts until formal standardization occurs. Code 418 (I'm a teapot), originating from the satirical Hyper Text Coffee Pot Control Protocol (HTCPCP) in RFC 2324, humorously indicates that a server—envisioned as a —refuses to perform an incompatible task like . Extended in the April Fools' Day RFC 7168 to support tea-related extensions, it is not intended for production environments and is marked as unused in the IANA registry, with warnings against its misuse in serious applications to avoid confusion or protocol bloat. This code exemplifies reserved slots that preserve namespace while highlighting the protocol's occasional levity.

References

  1. https://datatracker.ietf.org/doc/html/rfc9110#section-15
  2. https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
  3. https://www.rfc-editor.org/rfc/rfc9110.html#section-15
  4. https://www.iana.org/assignments/http-status-codes
  5. https://www.rfc-editor.org/rfc/rfc9110.html#section-16.2.1
  6. https://www.hostinger.com/tutorials/http-status-codes
  7. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.2
  8. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.2.1
  9. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.2.2
  10. https://www.rfc-editor.org/rfc/rfc2518.html#section-10.1
  11. https://www.rfc-editor.org/rfc/rfc8297.html
  12. https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-resumable-upload-10
  13. https://www.rfc-editor.org/rfc/rfc9110.html
  14. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.1
  15. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.2
  16. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.3
  17. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.4
  18. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.5
  19. https://www.siteground.com/kb/204-status-code/
  20. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.6
  21. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.7
  22. https://www.rfc-editor.org/rfc/rfc4918.html#section-11.1
  23. https://www.rfc-editor.org/rfc/rfc5842.html#section-7.1
  24. https://www.rfc-editor.org/rfc/rfc3229.html#section-10.2
  25. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.4
  26. https://www.rfc-editor.org/rfc/rfc9110.html#section-10.2.2
  27. https://www.rfc-editor.org/rfc/rfc9110.html#status.300
  28. https://www.rfc-editor.org/rfc/rfc9110.html#section-12.4
  29. https://www.rfc-editor.org/rfc/rfc9110.html#status.301
  30. https://www.rfc-editor.org/rfc/rfc9110.html#status.302
  31. https://www.rfc-editor.org/rfc/rfc9110.html#status.303
  32. https://www.rfc-editor.org/rfc/rfc9110.html#status.304
  33. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.5
  34. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.4.6
  35. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.4.7
  36. https://www.rfc-editor.org/rfc/rfc9110.html#status.307
  37. https://datatracker.ietf.org/doc/html/rfc7238
  38. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.1
  39. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.2
  40. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.3
  41. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.4
  42. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.5
  43. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.6
  44. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.7
  45. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.8
  46. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.9
  47. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.10
  48. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.11
  49. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.12
  50. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.13
  51. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.14
  52. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.15
  53. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.16
  54. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.17
  55. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.18
  56. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.19
  57. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.20
  58. https://datatracker.ietf.org/doc/html/rfc4918#section-11.3
  59. https://datatracker.ietf.org/doc/html/rfc4918#section-10.4
  60. https://datatracker.ietf.org/doc/html/rfc4918#section-11.4
  61. https://datatracker.ietf.org/doc/html/rfc8470#section-5.2
  62. https://datatracker.ietf.org/doc/html/rfc8470#section-5.1
  63. https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.21
  64. https://datatracker.ietf.org/doc/html/rfc6585#section-3
  65. https://datatracker.ietf.org/doc/html/rfc6585#section-4
  66. https://datatracker.ietf.org/doc/html/rfc6585#section-5
  67. https://datatracker.ietf.org/doc/html/rfc7725#section-3
  68. https://datatracker.ietf.org/doc/html/rfc7725#section-4
  69. https://www.rfc-editor.org/rfc/rfc9110.html#status.5xx
  70. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status
  71. https://www.rfc-editor.org/rfc/rfc9110.html#status.500
  72. https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/iis/health-diagnostic-performance/http-status-code
  73. https://www.rfc-editor.org/rfc/rfc9110.html#status.501
  74. https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/iis/site-behavior-performance/http-error-501-not-implemented
  75. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/501
  76. https://www.rfc-editor.org/rfc/rfc9110.html#status.502
  77. https://www.rfc-editor.org/rfc/rfc9110.html#status.503
  78. https://www.rfc-editor.org/rfc/rfc9110.html#field.retry-after
  79. https://www.rfc-editor.org/rfc/rfc9110.html#status.504
  80. https://www.rfc-editor.org/rfc/rfc9110.html#status.505
  81. https://www.rfc-editor.org/rfc/rfc2295.html#section-8.1
  82. https://www.rfc-editor.org/rfc/rfc4918.html#section-11.5
  83. https://www.rfc-editor.org/rfc/rfc5842.html#section-7.4
  84. https://datatracker.ietf.org/doc/html/rfc6585#section-6
  85. https://datatracker.ietf.org/doc/html/rfc4918
  86. https://datatracker.ietf.org/doc/html/rfc4918#section-11.1
  87. https://datatracker.ietf.org/doc/html/rfc4918#section-9.1
  88. https://datatracker.ietf.org/doc/html/rfc4918#section-13
  89. https://datatracker.ietf.org/doc/html/rfc5842#section-7.1
  90. https://datatracker.ietf.org/doc/html/rfc4918#section-11.2
  91. https://datatracker.ietf.org/doc/html/rfc4918#section-7.4
  92. https://datatracker.ietf.org/doc/html/rfc4918#section-9.2.2
  93. https://datatracker.ietf.org/doc/html/rfc3229#section-10.4.1
  94. https://datatracker.ietf.org/doc/html/rfc3229#section-5.2
  95. https://blogs.iis.net/ma_khan/troubleshooting-iis-6-status-and-substatus-codes
  96. https://nginx.org/en/docs/http/ngx_http_ssl_module.html
  97. https://nginx.org/en/docs/http/ngx_http_core_module.html#error_page
  98. https://httpd.apache.org/docs/2.4/custom-error.html
  99. https://nginx.org/en/docs/http/ngx_http_core_module.html
  100. https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/
  101. https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-520/
  102. https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-521/
  103. https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-522/
  104. https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-523/
  105. https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-524/
  106. https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-525/
  107. https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-526/
  108. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html
  109. https://www.rfc-editor.org/rfc/rfc2616.html#section-14.46
  110. https://www.rfc-editor.org/rfc/rfc2616.html#section-13.1.2
  111. https://www.rfc-editor.org/rfc/rfc2616.html#section-13.2.4
  112. https://www.rfc-editor.org/rfc/rfc2616.html#section-13.5.2
  113. https://www.rfc-editor.org/rfc/rfc2616.html#section-13.5.3
  114. https://www.rfc-editor.org/rfc/rfc9111.html#section-5.5
  115. https://www.rfc-editor.org/rfc/rfc9111.html#section-8.3
  116. https://www.iana.org/assignments/http-status-codes/http-status-codes.txt
  117. https://www.rfc-editor.org/rfc/rfc9110.html#section-15.5.2
  118. https://www.rfc-editor.org/rfc/rfc7168.html#section-2.4.1
Add your contribution
Related Hubs
User Avatar
No comments yet.