Skip to main content

HTTP status codes

Summary

Hypertext Transfer Protocol (HTTP) response status codes are standardized, three-digit messages from servers indicating the outcome of client requests. They help diagnose issues, optimize performance, and facilitate smooth client-server communication.

Introduction #

Hypertext Transfer Protocol (HTTP) response status codes are standardized, three-digit responses issued by a web server when it receives a request from a client, such as a browser or an application. These codes are part of the HTTP protocol and communicate the outcome of the request, whether it was successful, encountered an error, or requires further action.

Status codes are valuable tools for troubleshooting issues between clients and servers. By providing specific feedback on the outcome of a request, these codes allow developers and network administrators to quickly identify the nature of the problem.

If you receive a response code that is not part of the official HTTP status response code list, it is a non-standard response, likely specific to the server's software.

By interpreting these codes, troubleshooting can be faster and more efficient, enabling quicker diagnosis and resolution of network or application issues.

Status code categories #

HTTP status response codes are divided into five categories, each representing a specific type of outcome in client-server communication. These categories help classify how the server responds to a client’s request, making it easier to understand the nature of the interaction.

Each of these categories contains specific status codes that provide more detail on the exact nature of the response.

List of HTTP response status codes #

1xx - Informational #

Informational 1xx status codes indicate that the server has received the request and is continuing to process it, often requiring the client to wait for a final response.

List of 1xx status response codes
CodeNameReference

100

Continue

This interim response indicates that the client should continue the request or ignore the response if the request is already finished.

RFC9110, Section 15.2.1

101

Switching Protocols

This code is sent in response to an Upgrade request header from the client and indicates the protocol the server is switching to.

RFC9110, Section 15.2.2

102

Processing

This code indicates that the server has received and is processing the request, but no response is available yet.

RFC2518

103

Early Hints

This status code is primarily intended to be used with the Link header, letting the user agent start preloading resources while the server prepares a response or preconnect to an origin from which the page will need resources.

RFC8297

104-199

Unassigned

2xx - Success #

Success 2xx status codes indicate that the client’s request was successfully received, understood, and processed by the server.

List of 2xx status response codes
CodeNameReference

200

OK

Depending on the HTTP method: GET: The resource has been fetched and transmitted in the message body. HEAD: The representation headers are included in the response without any message body. PUT or POST: The resource describing the result of the action is transmitted in the message body. TRACE: The message body contains the request message as received by the server.

RFC9110, Section 15.3.1

201

Created

The request succeeded, and a new resource was created as a result. This is typically the response sent after POST requests, or some PUT requests.

RFC9110, Section 15.3.2

202

Accepted

The request has been received but remains unprocessed, reflecting a noncommittal status since HTTP does not allow for asynchronous responses to indicate the request's outcome. This status is designed for situations where another process or server manages the request, or for batch processing scenarios.

RFC9110, Section 15.3.3

203

Non-Authoritative Information

This response code indicates that the returned metadata differs slightly from what is available on the origin server, as it has been sourced from a local or third-party copy. It is primarily used for mirrors or backups of other resources; otherwise, the 200 OK response is generally preferred over this status.

RFC9110, Section 15.3.4

204

No Content

There is no content to send for this request, but the headers may provide useful information. The user agent may update its cached headers for this resource with the new ones provided.

RFC9110, Section 15.3.5

205

Reset Content

Tells the user agent to reset the document which sent this request.

RFC9110, Section 15.3.6

206

Partial Content

This response code is utilized when the client sends a Range header to request only a portion of a resource.

RFC9110, Section 15.3.7

207

Multi-Status

Conveys information about multiple resources, for situations where multiple status codes might be appropriate.

RFC4918

208

Already Reported

Used inside a <dav:propstat> response element to avoid repeatedly enumerating the internal members of multiple bindings to the same collection.

RFC5842

209-225

Unassigned

226

IM Used

The server has successfully fulfilled a GET request for the resource, and the response represents the result of one or more instance manipulations applied to the current instance.

RFC3229

227-299

Unassigned

3xx - Redirection #

Redirection 3xx status codes indicate that further action is required by the client to complete the request, often involving a different resource or URL.

List of 3xx status response codes
CodeNameReference

300

Multiple Choices

The request has multiple possible responses, and the user agent or user should select one of them. While there is no standardized method for making this selection, it is recommended to provide HTML links to the available options so the user can choose.

RFC9110, Section 15.4.1

301

Moved Permanently

The URL of the requested resource has been changed permanently. The new URL is given in the response.

RFC9110, Section 15.4.2

302

Found

The URI of the requested resource has been temporarily changed, with the possibility of further changes in the future. As a result, the client should continue to use the same URI for future requests.

RFC9110, Section 15.4.3

303

See Other

The server sent this response to direct the client to get the requested resource at another URI with a GET request.

RFC9110, Section 15.4.4

304

Not Modified

This is used for caching purposes, informing the client that the response has not been modified, allowing the client to continue using the same cached version of the response.

RFC9110, Section 15.4.5

305

Use Proxy

The status code was defined in a previous version of the specification and is now deprecated.

RFC9110, Section 15.4.6

306

(Unused)

Originally defined in an earlier version of the HTTP specification, this status indicated that a requested response must be accessed through a proxy. It has been deprecated due to security concerns related to the in-band configuration of proxies.

RFC9110, Section 15.4.7

307

Temporary Redirect

The server sends this response to direct the client to get the requested resource at another URI with the same method that was used in the prior request. This has the same semantics as the 302 Found HTTP response code, with the exception that the user agent must not change the HTTP method used: if a POST was used in the first request, a POST must be used in the second request.

RFC9110, Section 15.4.8

308

Permanent Redirect

The permanent redirect 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.

RFC9110, Section 15.4.9

309-399

Unassigned

4xx - Client Errors #

Error 4xx status codes indicate that the client made an invalid request, resulting in the server being unable to process it, often due to issues like missing resources or incorrect data.

List of 4xx status response codes
CodeNameReference

400

Bad Request

The server cannot or will not process the request because it is perceived as a client error, such as malformed request syntax, invalid request message framing, or deceptive request routing.

RFC9110, Section 15.5.1

401

Unauthorized

While the HTTP standard specifies "unauthorized," this response semantically means "unauthenticated," indicating that the client must authenticate itself to receive the requested response.

RFC9110, Section 15.5.2

402

Payment Required

This response code is reserved for future use. Originally intended for digital payment systems, it is rarely utilized, and no standard convention currently exists for its application.

RFC9110, Section 15.5.3

403

Forbidden

The client lacks access rights to the content, meaning it is unauthorized, and the server is refusing to provide the requested resource. Unlike the 401 Unauthorized status, the server is aware of the client's identity.

RFC9110, Section 15.5.4

404

Not Found

The server cannot find the requested resource. In a browser, this indicates that the URL is unrecognized, while in an API, it may signify that the endpoint is valid but the specific resource does not exist. Servers may also use this response instead of a 403 Forbidden to conceal the existence of a resource from unauthorized clients. This response code is likely the most well-known due to its frequent appearance on the web.

RFC9110, Section 15.5.5

405

Method Not Allowed

The request method is recognized by the server but is not supported by the target resource. For instance, an API may not permit the use of DELETE to remove a resource.

RFC9110, Section 15.5.6

406

Not Acceptable

This response is sent when the web server, after conducting server-driven content negotiation, fails to find any content that meets the criteria specified by the user agent.

RFC9110, Section 15.5.7

407

Proxy Authentication Required

This is similar to 401 Unauthorized but authentication is needed to be done by a proxy.

RFC9110, Section 15.5.8

408

Request Timeout

This response is sent by some servers on an idle connection, even in the absence of any prior request from the client, indicating that the server intends to close the unused connection. Some servers may simply terminate the connection without sending this message.

RFC9110, Section 15.5.9

409

Conflict

This response is sent when a request conflicts with the current state of the server.

RFC9110, Section 15.5.10

410

Gone

This response is sent when the requested content has been permanently deleted from the server, without any forwarding address. Clients are expected to remove their caches and links to the resource. The HTTP specification designates this status code for use with "limited-time, promotional services."

RFC9110, Section 15.5.11

411

Length Required

Server rejected the request because the Content-Length header field is not defined and the server requires it.

RFC9110, Section 15.5.12

412

Precondition Failed

The client has indicated preconditions in its headers which the server does not meet.

RFC9110, Section 15.5.13

413

Content Too Large

The requested payload is larger than the limits set by the server. The server may either close the connection or return a Retry-After header field.

RFC9110, Section 15.5.14

414

URI Too Long

The URI requested by the client exceeds the length that the server is willing to process.

RFC9110, Section 15.5.15

415

Unsupported Media Type

The server does not support the media format of the requested data, resulting in the rejection of the request.

RFC9110, Section 15.5.16

416

Range Not Satisfiable

The range specified by the Range header in the request can not be fulfilled, possibly because the range exceeds the size of the data for the target URI.

RFC9110, Section 15.5.17

417

Expectation Failed

This response code indicates that the server cannot fulfill the expectation specified by the Expect request header field.

RFC9110, Section 15.5.18

418

(Unused)

Known as the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) which used to state that the server refuses the attempt to brew coffee with a teapot. The status code was an April 1 RFC that lampooned the various ways HTTP was abused; one such abuse was the definition of an application-specific 418 status code, which has been deployed as a joke often enough for the code to be unusable for any future use.

RFC9110, Section 15.5.19

419-420

Unassigned

421

Misdirected Request

The request was directed to a server that is unable to generate a response. This may occur if the server is not configured to handle responses for the specific combination of scheme and authority present in the request URI.

RFC9110, Section 15.5.20

422

Unprocessable Content

The server recognizes the content type of the request (making a 415 Unsupported Media Type status code inappropriate) and the syntax of the request content is correct; however, it was unable to process the instructions contained within.

RFC9110, Section 15.5.21

423

Locked

The destination resource, or resource within the destination collection, was locked.

RFC4918

424

Failed Dependency

The request failed due to failure of a previous request.

RFC4918

425

Too Early

Indicates that the server is reluctant to process a request that could potentially be replayed.

RFC8470

426

Upgrade Required

The server refuses to fulfill the request using the current protocol but may be willing to do so if the client upgrades to a different protocol. The server includes an Upgrade header in the 426 response to specify the required protocol(s).

RFC9110, Section 15.5.22

427

Unassigned

428

Precondition Required

The 428 status code indicates that the origin server requires the request to be conditional.

RFC6585

429

Too Many Requests

The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting")

RFC6585

430

Unassigned

431

Request Header Fields Too Large

The 431 status code indicates that the server is unwilling to process the request because its header fields are too large.

RFC6585

432-450

Unassigned

451

Unavailable For Legal Reasons

This status code indicates that the server is denying access to the resource as a consequence of a legal demand.

RFC7725

452-499

Unassigned

5xx - Server Errors #

Server error 5xx status codes indicate that the server encountered an error while processing a valid request, meaning the issue lies on the server side rather than with the client’s request.

List of 5xx status response codes
CodeNameReference

500

Internal Server Error

The server encountered an unexpected condition that prevented it from fulfilling the request.

RFC9110, Section 15.6.1

501

Not Implemented

The server does not support the functionality necessary to fulfill the request. This response is appropriate when the server does not recognize the request method and cannot support it for any resource.

RFC9110, Section 15.6.2

502

Bad Gateway

This error response indicates that the server, acting as a gateway to obtain a necessary response for handling the request, received an invalid response.

RFC9110, Section 15.6.3

503

Service Unavailable

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.

RFC9110, Section 15.6.4

504

Gateway Timeout

While acting as a gateway or proxy, the server did not receive a timely response from an upstream server that it needed to access to complete the request.

RFC9110, Section 15.6.5

505

HTTP Version Not Supported

The server does not support, or refuses to support, the major version of HTTP that was used in the request message.

RFC9110, Section 15.6.6

506

Variant Also Negotiates

The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.

RFC2295

507

Insufficient Storage

The method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request.

RFC4918

508

Loop Detected

The server terminated an operation due to encountering an infinite loop while processing a request with "Depth: infinity." This status indicates that the entire operation has failed.

RFC5842

509

Unassigned

510

Not Extended (OBSOLETED)

The policy for accessing the resource has not been met in the request. The server should send back all the information necessary for the client to issue an extended request.

RFC2774

511

Network Authentication Required

The 511 status code indicates that the client needs to authenticate to gain network access.

RFC6585

512-599

Unassigned

Development #

The response status codes are defined in Request for Comments (RFCs) by the members of the Internet Engineering Task Force (IETF) and the HTTP Working Group (HTTPWG).

The HTTP status codes are published in the Hypertext Transfer Protocol (HTTP) Status Code Registry by Internet Assigned Numbers Authority (IANA).


Further readings #

Sources and recommended, further resources on the topic:

Author

Jonas Jared Jacek • J15k

Jonas Jared Jacek (J15k)

Jonas works as project manager, web designer, and web developer since 2001. On top of that, he is a Linux system administrator with a broad interest in things related to programming, architecture, and design. See: https://www.j15k.com/

License

License: HTTP status codes by Jonas Jared Jacek is licensed under CC BY-SA 4.0.

This license requires that reusers give credit to the creator. It allows reusers to distribute, remix, adapt, and build upon the material in any medium or format, for noncommercial purposes only. To give credit, provide a link back to the original source, the author, and the license e.g. like this:

<p xmlns:cc="http://creativecommons.org/ns#" xmlns:dct="http://purl.org/dc/terms/"><a property="dct:title" rel="cc:attributionURL" href="https://www.ditig.com/publications/http-status-codes">HTTP status codes</a> by <a rel="cc:attributionURL dct:creator" property="cc:attributionName" href="https://www.j15k.com/">Jonas Jared Jacek</a> is licensed under <a href="https://creativecommons.org/licenses/by-sa/4.0/" target="_blank" rel="license noopener noreferrer">CC BY-SA 4.0</a>.</p>

For more information see the DITig legal page.


“Learning from conventions will make your site better.”

Jeffrey Veen, American designer and design strategistThe Art & Science of Web Design, - IT quotes