MiServe DevTools

Your lid

Pin tools here. They are saved in this browser.

HTTP Status Codes Reference

HTTP status codes from 100 to 511, with what each one means for a developer and the RFC that defines it, plus non-standard codes used by nginx, Cloudflare and other products.

78 status codes.

1xx Informational

The server has received the request and is still working on it. These are interim responses, sent before the final one.

100 Continue
The server has received the request headers and the client may send the body. A client asks for this by sending Expect: 100-continue before a large upload. RFC 9110
101 Switching Protocols
The server agrees to change the protocol on this connection, as the Upgrade header asked. A WebSocket connection starts this way. RFC 9110
102 Processing
The server has accepted a WebDAV request and is still working on it, so the client should not time out. The current WebDAV specification no longer includes it and it is rarely sent. RFC 2518
103 Early Hints
Sent before the final response with Link headers, so that the browser can start to preload resources or open connections while the server prepares the page. RFC 8297

2xx Successful

The request was received, understood and accepted.

200 OK
The request succeeded. The body holds the result: the resource for GET, or the outcome of the action for POST. RFC 9110
201 Created
The request created a new resource. The Location header usually gives its URL. RFC 9110
202 Accepted
The request was accepted for processing that has not finished and may still fail. It is typical for work placed on a queue. RFC 9110
203 Non-Authoritative Information
The request succeeded, but a proxy has changed the response that the origin server sent. RFC 9110
204 No Content
The request succeeded and there is no body to send. It is common for DELETE, and for PUT or PATCH when the client already has the new state. RFC 9110
205 Reset Content
The request succeeded and the client should reset the view that sent it, for example by clearing a form. There is no body. RFC 9110
206 Partial Content
The body holds only the byte range that the Range header asked for. It is used to resume downloads and to seek in video. RFC 9110
207 Multi-Status
The body is an XML document with a separate status for each of several resources. WebDAV uses it. RFC 4918
208 Already Reported
Inside a WebDAV Multi-Status response, it marks the members of a binding that were already listed, so that they are not repeated. RFC 5842
226 IM Used
The body is the result of applying one or more instance manipulations, such as a delta, to the current resource. It belongs to delta encoding in HTTP, which is rarely implemented. RFC 3229

3xx Redirection

The client has to take a further step to complete the request, usually a request to another URL.

300 Multiple Choices
The resource has several representations and the client may choose one. It is rarely used, because there is no standard way to make the choice. RFC 9110
301 Moved Permanently
A permanent redirect: the resource has a new URL, given in the Location header, and search engines usually index that URL in its place. Clients may change POST to GET when they follow it; use 308 to keep the method. RFC 9110
302 Found
A temporary redirect: for now the resource is at another URL, given in the Location header. Clients may change POST to GET when they follow it; use 307 to keep the method. RFC 9110
303 See Other
The answer is at another URL, which the client should fetch with GET. It is the usual redirect after a form POST, so that reloading the page does not submit the form again. RFC 9110
304 Not Modified
The copy in the client's cache is still current, so no body is sent. It answers a conditional request made with If-None-Match or If-Modified-Since. RFC 9110
305 Use Proxy
The resource must be reached through the proxy named in the Location header. It is deprecated for security reasons, and clients should not rely on it. RFC 9110
306 (Unused)
An earlier version of the specification used this code. It is no longer used, and the number stays reserved. RFC 9110
307 Temporary Redirect
The resource is temporarily at another URL, and the client must repeat the request there with the same method and body. RFC 9110
308 Permanent Redirect
The resource has a new permanent URL, and the client must repeat the request there with the same method and body. RFC 9110

4xx Client Error

The request has a fault on the client's side: it is malformed, lacks permission, or asks for something that cannot be served.

400 Bad Request
The server cannot process the request because it is malformed: the syntax is wrong, the framing is invalid or the body cannot be parsed. RFC 9110
401 Unauthorized
The request lacks valid credentials. The WWW-Authenticate header of the response says how to authenticate. Despite its name, the code is about authentication, not permission. RFC 9110
402 Payment Required
Reserved for future use. Some APIs send it when a subscription has ended or a paid quota is used up. RFC 9110
403 Forbidden
The server understood the request and refuses it. If the request carried credentials, they do not give permission to use this resource, and sending them again will not help. RFC 9110
404 Not Found
The server has nothing at this URL, or does not want to reveal that it has. The code does not say whether the absence is permanent. RFC 9110
405 Method Not Allowed
The resource exists but does not support this method. The Allow header lists the methods that it supports. RFC 9110
406 Not Acceptable
The server cannot produce a response that satisfies the Accept, Accept-Language or Accept-Encoding headers of the request. RFC 9110
407 Proxy Authentication Required
Like 401, but the client must authenticate with the proxy, as the Proxy-Authenticate header describes. RFC 9110
408 Request Timeout
The server did not receive the complete request within the time it was prepared to wait, and it closes the connection. RFC 9110
409 Conflict
The request conflicts with the current state of the resource, for example an edit based on an outdated version or a duplicate of a unique value. RFC 9110
410 Gone
The resource used to be here and has been removed for good. Unlike 404, it tells clients and search engines that they can drop the URL. RFC 9110
411 Length Required
The server refuses the request because it has no Content-Length header. RFC 9110
412 Precondition Failed
A condition in If-Match, If-Unmodified-Since or a similar header was false, so the request was not applied. It protects against overwriting a change made by someone else. RFC 9110
413 Content Too Large
The request body is larger than the server accepts, usually because of an upload limit in the server or in a proxy in front of it. Its earlier name was Payload Too Large. RFC 9110
414 URI Too Long
The URL is longer than the server accepts. It often means that data which belongs in a POST body was put in the query string. RFC 9110
415 Unsupported Media Type
The server does not accept the format of the request body, as declared in the Content-Type or Content-Encoding header. RFC 9110
416 Range Not Satisfiable
The Range header asks for bytes that lie outside the resource. RFC 9110
417 Expectation Failed
The server cannot meet the requirement given in the Expect header of the request. RFC 9110
418 I'm a teapot
An April Fools' joke from the Hyper Text Coffee Pot Control Protocol, in which a teapot refuses to brew coffee. RFC 9110 lists the number as unused and keeps it reserved, because it has been deployed as a joke too often to be given another meaning. RFC 2324, RFC 9110
421 Misdirected Request
The request reached a server that is not configured to answer for this host name. It can happen when a browser reuses an HTTP/2 connection for another host; the client may retry on a new connection. RFC 9110
422 Unprocessable Content
The syntax of the request is correct but its content is not valid, for example a JSON body that fails validation. It comes from WebDAV, where its name was Unprocessable Entity. RFC 9110, RFC 4918
423 Locked
The WebDAV resource is locked, so the method cannot be applied to it. RFC 4918
424 Failed Dependency
The method was not carried out on this WebDAV resource because another action that it depended on failed. RFC 4918
425 Too Early
The server will not process a request that arrived in TLS early data, because it could be a replay. The client should send it again after the handshake has finished. RFC 8470
426 Upgrade Required
The server refuses the request over this protocol and names, in the Upgrade header, the protocol that the client must switch to. RFC 9110
428 Precondition Required
The server requires the request to be conditional, for example with If-Match, so that an update cannot silently overwrite a newer version. RFC 6585
429 Too Many Requests
The client has sent too many requests in a given time, which is called rate limiting. The Retry-After header may say how long to wait. RFC 6585
431 Request Header Fields Too Large
The headers together, or one of them, are larger than the server accepts. An oversized cookie is a common cause. RFC 6585
451 Unavailable For Legal Reasons
The server denies access because of a legal demand, such as a court order. The number refers to the novel Fahrenheit 451. RFC 7725

5xx Server Error

The request may be valid, but the server or a gateway in front of it failed to fulfil it.

500 Internal Server Error
The server met a condition that it did not expect, often an unhandled exception. The server's logs are the place to look for the cause. RFC 9110
501 Not Implemented
The server does not support the functionality that the request needs, for example a method that it does not recognise. RFC 9110
502 Bad Gateway
A gateway or proxy received an invalid response from the server behind it. Often the application behind the proxy has crashed or is not listening. RFC 9110
503 Service Unavailable
The server cannot handle the request at the moment, because of overload or maintenance. The Retry-After header may say when to try again. RFC 9110
504 Gateway Timeout
A gateway or proxy did not receive a response in time from the server behind it. Often the application is too slow or cannot be reached. RFC 9110
505 HTTP Version Not Supported
The server does not support the major version of HTTP that the request used. RFC 9110
506 Variant Also Negotiates
The server is misconfigured: the variant chosen by transparent content negotiation is itself set up to negotiate, which makes a loop. RFC 2295
507 Insufficient Storage
The server cannot store what it needs to complete the request. It is defined for WebDAV. RFC 4918
508 Loop Detected
The server stopped a WebDAV operation because it found an infinite loop while it followed bindings. RFC 5842
510 Not Extended
The request lacks an extension that the server requires. The specification that defined the code is now historic, and the IANA registry marks the code as obsoleted. RFC 2774
511 Network Authentication Required
The client must authenticate to get access to the network. A captive portal sends it, such as the sign-in page of a hotel Wi-Fi, and not the site that was asked for. RFC 6585

Non-standard codes

These codes are not in the IANA registry. Each one belongs to a particular server or service, and its meaning holds only there.

419 Page Expired Non-standard
Laravel sends it when the CSRF token of a form is missing or has expired. Laravel
444 No Response Non-standard
An nginx configuration can return 444 to close the connection without sending a response. It appears in the nginx log, and the client receives nothing. nginx
494 Request Header Too Large Non-standard
nginx uses it internally when the request headers do not fit in its buffers. The client is sent a 400 response. nginx
495 SSL Certificate Error Non-standard
nginx uses it internally when the verification of a client certificate fails. Unless the configuration handles it, the client is sent a 400 response. nginx
496 SSL Certificate Required Non-standard
nginx uses it internally when the client did not present the certificate that the server requires. nginx
497 HTTP Request Sent to HTTPS Port Non-standard
nginx uses it internally when a plain HTTP request arrives on a port that expects HTTPS. nginx
499 Client Closed Request Non-standard
nginx logs it when the client closed the connection before the server had answered. It often means that the client's timeout is shorter than the time the application takes. nginx
509 Bandwidth Limit Exceeded Non-standard
Hosting control panels such as cPanel send it when a site has used up its bandwidth allowance. cPanel
520 Web Server Returned an Unknown Error Non-standard
Cloudflare sends it when the origin server returned an empty, unknown or unexpected response. Cloudflare
521 Web Server Is Down Non-standard
Cloudflare sends it when the origin server refused its connection. Cloudflare
522 Connection Timed Out Non-standard
Cloudflare sends it when it could not complete a TCP connection to the origin server in time. Cloudflare
523 Origin Is Unreachable Non-standard
Cloudflare sends it when it could not reach the origin server, for example because of a wrong DNS record or a routing problem. Cloudflare
524 A Timeout Occurred Non-standard
Cloudflare connected to the origin server, but the origin did not send an HTTP response in time. Cloudflare
525 SSL Handshake Failed Non-standard
Cloudflare sends it when the TLS handshake between Cloudflare and the origin server failed. Cloudflare
526 Invalid SSL Certificate Non-standard
Cloudflare sends it when it could not validate the TLS certificate of the origin server. Cloudflare

Runs in your browser. Nothing you paste is uploaded.

About this tool

How status codes are organised

Every HTTP response starts with a three-digit status code. The first digit is the class: 1xx is an interim answer, 2xx means success, 3xx asks the client to go elsewhere, 4xx says the request was at fault and 5xx says the server was. A client that meets a code it does not know must treat it like the first code of its class, so an unknown 4xx is handled as 400.

The text after the number, such as Not Found, is the reason phrase. It is only a description for people: clients are told to ignore it, and HTTP/2 and HTTP/3 do not send it at all. The names of the standard codes in this list are the ones in the IANA registry, except for 418, which the registry lists as (Unused).

Codes that are often confused

401 and 403. 401 means that the server does not know who you are, and authenticating may help. 403 means that the server refuses the request and that authenticating again will not change the answer.

301, 302, 307 and 308. 301 and 308 are permanent, 302 and 307 are temporary. With 301 and 302 a client may turn a POST into a GET when it follows the redirect; 307 and 308 require the same method and body.

502 and 504. Both come from a proxy or load balancer in front of the application. With 502 the proxy received something invalid or the connection failed; with 504 it waited and received nothing in time.

404 and 410. 404 says that nothing is here, perhaps only for now. 410 says that the resource has been removed for good.

Where this list comes from

The standard codes come from the IANA HTTP Status Code Registry. Most are defined in RFC 9110, HTTP Semantics, which replaced RFC 7231 in 2022. The others come from WebDAV and from smaller extensions, and each entry names its RFC. Temporary registrations that are still Internet-Drafts are left out. The last group holds codes that are not registered but that appear in the logs and error pages of nginx, Cloudflare and other products.

The whole list is part of the page, so it can be read without JavaScript. The search field filters it in your browser.

Questions

What is the difference between 401 and 403?

401 Unauthorized means that the request has no valid credentials, and the client may try again after authenticating. 403 Forbidden means that the server understood the request and refuses it: any credentials that were sent do not give access, so sending them again will not help.

Should a permanent redirect use 301 or 308?

Both tell clients and search engines that the URL has moved for good. With 301 a client is allowed to change a POST into a GET when it follows the redirect, while 308 requires the same method and body. For ordinary page URLs requested with GET the two behave the same.

What is the difference between 502 and 504?

Both are sent by a proxy, gateway or load balancer, not by the application. 502 Bad Gateway means that the server behind it gave an invalid response or refused the connection. 504 Gateway Timeout means that it did not answer within the proxy's time limit.

Is 499 a real HTTP status code?

It is not registered with IANA. nginx writes 499 in its access log when the client closed the connection before the response was sent, so no client ever receives it. Other products use numbers outside the registry in a similar way, such as 520 to 526 from Cloudflare.

More in Network