HTTP Status Codes

18 min readApr 2, 2021

What are HTTP status codes?

HTTP status codes are response codes that are returned by web servers along with responses indicating whether a request sent by the client was processed successfully or not.

There are five classes of HTTP status codes available.

1xx: Informational - Request received, continuing process
2xx: Success - The action was successfully received, understood, and accepted3xx: Redirection - Further action must be taken in order to complete the request4xx: Client Error - The request contains bad syntax or cannot be fulfilled5xx: Server Error - The server failed to fulfill an apparently valid request

1xx Informational

100 Continue

The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed.

101 Switching Protocols

The server understands and is willing to comply with the client’s request, via the Upgrade message header field, for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response’s Upgrade header field immediately after the empty line which terminates the 101 response.

The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.

102 Processing

The 102 (Processing) status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete.

103 Early Hints

The 103 (Early Hints) informational status code indicates to the

the client that the server is likely to send a final response with the

header fields included in the informational response.

2xx Success

200 OK

The 200 (OK) status code indicates that the request has succeeded.
The payload sent in a 200 response depends on the request method.
For the methods defined by this specification, the intended meaning
of the payload can be summarized as:

GET a representation of the target resource;

HEAD the same representation as GET, but without the representation
data;

POST a representation of the status of, or results obtained from,
the action;

PUT, DELETE a representation of the status of the action;

OPTIONS a representation of the communications options;

TRACE a representation of the request message as received by the end
server.

Aside from responses to CONNECT, a 200 response always has a payload,
though an origin server MAY generate a payload body of zero length.
If no payload is desired, an origin server ought to send 204 (No
Content) instead. For CONNECT, no payload is allowed because the
successful result is a tunnel, which begins immediately after the 200
response header section.

201 Created

The 201 (Created) status code indicates that the request has been
fulfilled and has resulted in one or more new resources being
created. The primary resource created by the request is identified
by either a Location header field in the response or, if no Location
the field is received, by the effective request URI.

The 201 response payload typically describes and links to the
resource(s) created.

202 Accepted

The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed.
The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility in HTTP for re-sending a status code from an asynchronous operation.

The 202 response is intentionally noncommittal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
the batch-oriented process that is only run once per day) without
requiring that the user agent’s connection to the server persist
until the process is completed. The representation sent with this
response ought to describe the request’s current status and point to
(or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled.

203 Non-Authoritative Information

The 203 (Non-Authoritative Information) status code indicates that
the request was successful but the enclosed payload has been modified
from that of the origin server’s 200 (OK) response by a transforming
proxy. This status code allows the
proxy to notify recipients when a transformation has been applied,
since that knowledge might impact later decisions regarding the
content. For example, future cache validation requests for the
the content might only be applicable along the same request path (through
the same proxies).

The 203 response is similar to the Warning code of 214 Transformation
Applied, which has the advantage of being
applicable to responses with any status code.

204 No Content

The 204 (No Content) status code indicates that the server has
successfully fulfilled the request and that there is no additional
content to send in the response payload body. Metadata in the
response header fields refer to the target resource and its selected
representation after the requested action was applied.

For example, if a 204 status code is received in response to a PUT
request and the response contains an ETag header field, then the PUT
was successful and the ETag field-value contains the entity-tag for
the new representation of that target resource.

The 204 response allows a server to indicate that the action has been
successfully applied to the target resource, while implying that the
user agent does not need to traverse away from its current “document
view” (if any). The server assumes that the user agent will provide
some indication of the success to its user, in accord with its own
interface, and apply any new or updated metadata in the response to
its active representation.

For example, a 204 status code is commonly used with document editing interfaces corresponding to a “save” action, such that the document being saved remains available to the user for editing. It is also
frequently used with interfaces that expect automated data transfers
to be prevalent, such as within distributed version control systems.

A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body.

A 204 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls

205 Reset Content

The 205 (Reset Content) status code indicates that the server has
fulfilled the request and desires that the user agent reset the
“document view”, which caused the request to be sent, to its original
state as received from the origin server.

This response is intended to support a common data entry use case
where the user receives content that supports data entry (a form,
notepad, canvas, etc.), enters or manipulates data in that space,

causes the entered data to be submitted in a request, and then the
data entry mechanism is reset for the next entry so that the user can
easily initiate another input action.

Since the 205 status code implies that no additional content will be
provided, a server MUST NOT generate a payload in a 205 response.
In other words, a server MUST do one of the following for a 205
response: a) indicate a zero-length body for the response by
including a Content-Length header field with a value of 0; b)
indicate a zero-length payload for the response by including a
Transfer-Encoding header field with a value of chunked and a message
body consisting of a single chunk of zero-length; or, c) close the
connection immediately after sending the blank line terminating the
header section.

206 Partial Content

207 Multi-Status (WebDAV)

208 Already Reported (WebDAV)

226 IM Used

3xx Redirection

The 3xx (Redirection) class of status code indicates that further
action needs to be taken by the user agent in order to fulfill the
request. If a Location header field (Section 7.1.2) is provided, the
user agent MAY automatically redirect its request to the URI
referenced by the Location field value, even if the specific status
code is not understood. Automatic redirection needs to done with
care for methods not known to be safe, as defined in Section 4.2.1,
since the user might not wish to redirect an unsafe request.

There are several types of redirects:

1. Redirects that indicate the resource might be available at a
different URI, as provided by the Location field, as in the
status codes 301 (Moved Permanently), 302 (Found), and 307
(Temporary Redirect).

2. Redirection that offers a choice of matching resources, each
capable of representing the original request target, as in the
300 (Multiple Choices) status code.

3. Redirection to a different resource, identified by the Location
field, that can represent an indirect response to the request, as
in the 303 (See Other) status code.

4. Redirection to a previously cached result, as in the 304 (Not
Modified) status code.

Note: In HTTP/1.0, the status codes 301 (Moved Permanently) and
302 (Found) were defined for the first type of redirect
Early user agents split on whether the
method applied to the redirect target would be the same as the

original request or would be rewritten as GET. Although HTTP
originally defined the former semantics for 301 and 302 (to match
its original implementation at CERN), and defined 303
to match the latter semantics, prevailing practice gradually
converged on the latter semantics for 301 and 302 as well. The
first revision of HTTP/1.1 added 307 (Temporary Redirect) to
indicate the former semantics without being impacted by divergent
practice. Over 10 years later, most user agents still do method
rewriting for 301 and 302; therefore, this specification makes
that behavior conformant when the original request is POST.

A client SHOULD detect and intervene in cyclical redirections (i.e.,
“infinite” redirection loops).

Note: An earlier version of this specification recommended a
maximum of five redirections. Content developers need to be aware that some clients might implement such a fixed limitation.

300 Multiple Choices

The 300 (Multiple Choices) status code indicates that the target
resource has more than one representation, each with its own more
specific identifier, and information about the alternatives is being
provided so that the user (or user agent) can select a preferred
representation by redirecting its request to one or more of those
identifiers. In other words, the server desires that the user agent
engage in reactive negotiation to select the most appropriate
representation(s) for its needs.

If the server has a preferred choice, the server SHOULD generate a
Location header field containing a preferred choice’s URI reference.
The user agent MAY use the Location field value for automatic redirection.

For request methods other than HEAD, the server SHOULD generate a
payload in the 300 response containing a list of representation
metadata and URI reference(s) from which the user or user agent can
choose the one most preferred. The user agent MAY make a selection
from that list automatically if it understands the provided media
type. A specific format for automatic selection is not defined by
this specification because HTTP tries to remain orthogonal to the
definition of its payloads. In practice, the representation is
provided in some easily parsed format believed to be acceptable to
the user agent, as determined by shared design or content
negotiation, or in some commonly accepted hypertext format.

301 Moved Permanently

The 301 (Moved Permanently) status code indicates that the target
resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs.
Clients with link-editing capabilities ought to automatically re-link
references to the effective request URI to one or more of the new
references sent by the server, where possible.

The server SHOULD generate a Location header field in the response
containing a preferred URI reference for the new permanent URI. The
user agent MAY use the Location field value for automatic
redirection. The server’s response payload usually contains a short
hypertext note with a hyperlink to the new URI(s).

Note: For historical reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this
behavior is undesired, the 307 (Temporary Redirect) status code
can be used instead.

302 Found

The 302 (Found) status code indicates that the target resource
resides temporarily under a different URI. Since the redirection
might be altered on occasion, the client ought to continue to use the
effective request URI for future requests

The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY
use the Location field value for automatic redirection. The server’s
response payload usually contains a short hypertext note with a
hyperlink to the different URI(s).

303 See Other

The 303 (See Other) status code indicates that the server is
redirecting the user agent to a different resource, as indicated by a
URI in the Location header field, which is intended to provide an
indirect response to the original request. A user agent can perform
a retrieval request targeting that URI (a GET or HEAD request if
using HTTP), which might also be redirected, and present the eventual
result as an answer to the original request. Note that the new URI
in the Location header field is not considered equivalent to the
effective request URI.

This status code is applicable to any HTTP method. It is primarily
used to allow the output of a POST action to redirect the user agent
to a selected resource, since doing so provides the information
corresponding to the POST response in a form that can be separately
identified, bookmarked, and cached, independent of the original
request.

A 303 response to a GET request indicates that the origin server does
not have a representation of the target resource that can be
transferred by the server over HTTP. However, the Location field
value refers to a resource that is descriptive of the target
resource, such that making a retrieval request on that other resource
might result in a representation that is useful to recipients without
implying that it represents the original target resource. Note that
answers to the questions of what can be represented, what
representations are adequate, and what might be a useful description
are outside the scope of HTTP.

Except for responses to a HEAD request, the representation of a 303
response ought to contain a short hypertext note with a hyperlink to
the same URI reference provided in the Location header field.

304 Not Modified

If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.

The response MUST include the following header fields:

Date, unless its omission is required

If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one, caches will operate correctly.

ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant

If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.

If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.

If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.

305 Use Proxy

The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via proxy. 305 responses MUST only be generated by origin servers.

This specification and is now deprecated

306 (Unused)

307 Temporary Redirect

The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s), since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.

If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

308 Permanent Redirect (experimental)

The request, and all future requests should be repeated using another URI. 307 and 308 (as proposed) parallel the behaviours of 302 and 301, but do not require the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.

4xx Client Error

400 Bad Request

The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).

401 Unauthorized

The request requires user authentication. The response MUST include a WWW-Authenticate header field containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field. If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in “HTTP Authentication: Basic and Digest Access Authentication”.

402 Payment Required

The 402 (Payment Required) status code is reserved for future use.

403 Forbidden

The 403 (Forbidden) status code indicates that the server understood
the request but refuses to authorize it. A server that wishes to
make public why the request has been forbidden can describe that
reason in the response payload (if any).

If authentication credentials were provided in the request, the
server considers them insufficient to grant access. The client
SHOULD NOT automatically repeat the request with the same
credentials. The client MAY repeat the request with new or different
credentials. However, a request might be forbidden for reasons
unrelated to the credentials.

An origin server that wishes to “hide” the current existence of a
forbidden target resource MAY instead respond with a status code of
404 (Not Found).

404 Not Found

The 404 (Not Found) status code indicates that the origin server did
not find a current representation for the target resource or is not
willing to disclose that one exists. A 404 status code does not
indicate whether this lack of representation is temporary or
permanent; the 410 (Gone) status code is preferred over 404 if the
origin server knows, presumably through some configurable means, that
the condition is likely to be permanent.

405 Method Not Allowed

The 405 (Method Not Allowed) status code indicates that the method
received in the request-line is known by the origin server but not
supported by the target resource. The origin server MUST generate an
Allow header field in a 405 response containing a list of the target
resource’s currently supported methods.

406 Not Acceptable

The 406 (Not Acceptable) status code indicates that the target
resource does not have a current representation that would be
acceptable to the user agent, according to the proactive negotiation
header fields received in the request (Section 5.3), and the server
is unwilling to supply a default representation.

The server SHOULD generate a payload containing a list of available
representation characteristics and corresponding resource identifiers
from which the user or user agent can choose the one most
appropriate. A user agent MAY automatically select the most appropriate choice from that list. However, this specification does
not define any standard for such automatic selection

407 Proxy Authentication Required

This code is similar to 401 (Unauthorized) but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in “HTTP Authentication: Basic and Digest Access Authentication”.

408 Request Timeout

The 408 (Request Timeout) status code indicates that the server did not receive a complete request message within the time that it was prepared to wait. A server SHOULD send the “close” connection option in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If the client has an outstanding request in transit, the client MAY repeat that request on a new connection.

409 Conflict

The 409 (Conflict) status code indicates that the request could not
be completed due to a conflict with the current state of the target
resource. This code is used in situations where the user might be
able to resolve the conflict and resubmit the request. The server
SHOULD generate a payload that includes enough information for a user
to recognize the source of the conflict.

Conflicts are most likely to occur in response to a PUT request. For
example, if versioning were being used and the representation being
PUT included changes to a resource that conflict with those made by
an earlier (third-party) request, the origin server might use a 409
response to indicate that it can’t complete the request. In this
case, the response representation would likely contain information
useful for merging the differences based on the revision history.

410 Gone

The 410 (Gone) status code indicates that access to the target
resource is no longer available at the origin server and that this
condition is likely to be permanent. If the origin server does not know, or has no facility to determine, whether or not the condition
is permanent, the status code 404 (Not Found) ought to be used
instead.

The 410 response is primarily intended to assist the task of web
maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common
for limited-time, promotional services and for resources belonging to
individuals no longer associated with the origin server’s site. It
is not necessary to mark all permanently unavailable resources as
“gone” or to keep the mark for any length of time — that is left to
the discretion of the server owner.

411 Length Required

The 411 (Length Required) status code indicates that the server
refuses to accept the request without a defined Content-Length
The client MAY repeat the request if
it adds a valid Content-Length header field containing the length of
the message body in the request message.

412 Precondition Failed

413 Request Entity Too Large

The 413 (Payload Too Large) status code indicates that the server is
refusing to process a request because the request payload is larger
than the server is willing or able to process. The server MAY close
the connection to prevent the client from continuing the request.

If the condition is temporary, the server SHOULD generate a
Retry-After header field to indicate that it is temporary and after
what time the client MAY try again.

414 Request-URI Too Long

The 414 (URI Too Long) status code indicates that the server is
refusing to service the request because the request-target is longer than the server is willing to interpret.
This rare condition is only likely to occur when a client has
improperly converted a POST request to a GET request with long query
information, when the client has descended into a “black hole” of
redirection (e.g., a redirected URI prefix that points to a suffix of
itself) or when the server is under attack by a client attempting to
exploit potential security holes.

415 Unsupported Media Type

The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource.
The format problem might be due to the request’s indicated
Content-Type or Content-Encoding, or as a result of inspecting the
data directly.

416 Requested Range Not Satisfiable

417 Expectation Failed

The 417 (Expectation Failed) status code indicates that the expectation given in the request’s Expect header field could not be met by at least one of the inbound servers.

418 I’m a teapot (RFC 2324)

420 Enhance Your Calm (Twitter)

422 Unprocessable Entity (WebDAV)

423 Locked (WebDAV)

424 Failed Dependency (WebDAV)

425 Reserved for WebDAV

426 Upgrade Required

428 Precondition Required

429 Too Many Requests

431 Request Header Fields Too Large

444 No Response (Nginx)

449 Retry With (Microsoft)

450 Blocked by Windows Parental Controls (Microsoft)

451 Unavailable For Legal Reasons

499 Client Closed Request (Nginx)

5xx Server Error

500 Internal Server Error

The 500 (Internal Server Error) status code indicates that the server
encountered an unexpected condition that prevented it from fulfilling
the request.

501 Not Implemented

The 501 (Not Implemented) status code indicates that the server does
not support the functionality required to fulfill the request. This
is the appropriate response when the server does not recognize the
request method and is not capable of supporting it for any resource.

502 Bad Gateway

The 502 (Bad Gateway) status code indicates that the server, while
acting as a gateway or proxy, received an invalid response from an
inbound server it accessed while attempting to fulfill the request.

503 Service Unavailable

The 503 (Service Unavailable) status code indicates that the server
is currently unable to handle the request due to a temporary overload
or scheduled maintenance, which will likely be alleviated after some
delay. The server MAY send a Retry-After header field
(Section 7.1.3) to suggest an appropriate amount of time for the
client to wait before retrying the request.

Note: The existence of the 503 status code does not imply that a
server has to use it when becoming overloaded. Some servers might
simply refuse the connection.

504 Gateway Timeout

The 504 (Gateway Timeout) status code indicates that the server,
while acting as a gateway or proxy, did not receive a timely response
from an upstream server it needed to access in order to complete the
request.

505 HTTP Version Not Supported

The 505 (HTTP Version Not Supported) status code indicates that the server does not support, or refuses to support, the major version of
HTTP that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message. The server should generate a representation for the 505 response that describes why that version is not supported and what other protocols are supported by that server.