HTTP Status Codes

Every HTTP status code with what it means, when to send it and the RFC section that defines it — searchable by number or words.

Find a code

Code or wordsA number, a class like 4xx, or what happened.

Often confused

401: we don’t know who you are (log in). 403: we know, and the answer is no.
400: the request itself is malformed. 422: it parsed fine, but the values are invalid.
404: nothing here, no promise either way. 410: it was here and has been removed for good.
Both permanent. 308 guarantees a POST stays a POST; 301 lets clients switch to GET.
Both temporary. 307 guarantees the method is kept; 302 lets clients switch to GET.
303 says “now GET this other URL” — use it after a form POST.
502: the server behind the proxy answered badly or not at all. 504: it answered too slowly.
500: a bug. 503: temporarily unable — overload or maintenance; send Retry-After.

72 codes

100Continue
The server has received the request headers and the client should go on and send the body.
Only sent when the client asked with Expect: 100-continue, usually before uploading a large body, so it can stop early if the server would refuse it anyway.
Class
1xx · Informational
Defined in
RFC 9110 §15.2.1
Headers
Expect
101Switching Protocols
The server agrees to switch to the protocol named in the Upgrade header.
You see it when a connection becomes a WebSocket. After this response the bytes on the connection are no longer HTTP/1.1.
Class
1xx · Informational
Defined in
RFC 9110 §15.2.2
Headers
Upgrade, Connection
102ProcessingDon’t use
A WebDAV interim response saying the server is still working on the request.
Removed from WebDAV when RFC 4918 replaced RFC 2518, though still in the registry. Clients generally ignore it; don’t send it from new code.
Class
1xx · Informational
Defined in
RFC 2518 §10.1
103Early Hints
Sent before the final response so the browser can start preloading resources while the server is still working.
Carries Link headers such as rel=preload or rel=preconnect. The real response (200, 404…) follows on the same request.
Class
1xx · Informational
Defined in
RFC 8297
Headers
Link
200OK
The request succeeded. What the body contains depends on the method.
For GET the body is the resource; for POST it is the result of the action. Cacheable by default when the response allows it.
Class
2xx · Success
Defined in
RFC 9110 §15.3.1
Caching
Cacheable by default unless headers say otherwise (RFC 9110 §15.1)
201Created
The request created one or more new resources.
Send it after a POST (or PUT) that creates something, with a Location header pointing at the new resource.
Class
2xx · Success
Defined in
RFC 9110 §15.3.2
Headers
Location
202Accepted
The request was accepted for processing, but the work has not finished — it may still fail.
Use it for queued or background jobs. Tell the client where to check progress, for example with a status URL in the body or in Location.
Class
2xx · Success
Defined in
RFC 9110 §15.3.3
203Non-Authoritative Information
Success, but a proxy changed the content the origin server sent.
Sent by a transforming proxy instead of 200. Rarely seen in practice.
Class
2xx · Success
Defined in
RFC 9110 §15.3.4
Caching
Cacheable by default unless headers say otherwise (RFC 9110 §15.1)
204No Content
Success, and there is deliberately no body.
Common for DELETE, and for PUT or PATCH when the client already has what it needs. A 204 must not have a body; browsers stay on the current page.
Class
2xx · Success
Defined in
RFC 9110 §15.3.5
Caching
Cacheable by default unless headers say otherwise (RFC 9110 §15.1)
205Reset Content
Success; the client should reset the form or view that sent the request.
Meant for data-entry screens: clear the form for the next entry. Browsers largely ignore it.
Class
2xx · Success
Defined in
RFC 9110 §15.3.6
206Partial Content
The server is sending part of the resource, as asked for by a Range header.
This is how resumed downloads and video seeking work. Content-Range says which bytes are in the body.
Class
2xx · Success
Defined in
RFC 9110 §15.3.7
Headers
Range, Content-Range, Accept-Ranges
Caching
Cacheable by default unless headers say otherwise (RFC 9110 §15.1)
207Multi-Status
WebDAV: the body is an XML document with a separate status for each of several resources.
Used by WebDAV operations that touch many files at once, so each can succeed or fail on its own.
Class
2xx · Success
Defined in
RFC 4918 §11.1
208Already Reported
WebDAV: this member was already listed earlier in the same Multi-Status response.
Prevents a resource that is bound in several places from being listed again and again.
Class
2xx · Success
Defined in
RFC 5842 §7.1
226IM Used
The response is a delta — changes applied to the version the client already has.
Part of delta encoding for HTTP, which never saw wide use.
Class
2xx · Success
Defined in
RFC 3229 §10.4.1
300Multiple Choices
The resource has several representations and the client may choose one.
There is no standard format for the list of choices, so in practice servers pick one themselves and send 200 instead.
Class
3xx · Redirection
Defined in
RFC 9110 §15.4.1
Caching
Cacheable by default unless headers say otherwise (RFC 9110 §15.1)
301Moved Permanently
The resource has a new permanent URL, given in Location.
Browsers cache it and search engines move rankings to the new URL. Historically clients may turn a POST into a GET when following it — use 308 if the method must be kept.
Class
3xx · Redirection
Defined in
RFC 9110 §15.4.2
Headers
Location
Caching
Cacheable by default unless headers say otherwise (RFC 9110 §15.1)
302Found
The resource is temporarily at another URL, given in Location. Keep using the original URL.
Like 301, clients may change POST to GET when following it. Use 307 to keep the method, or 303 to deliberately switch to GET.
Class
3xx · Redirection
Defined in
RFC 9110 §15.4.3
Headers
Location
303See Other
Go and GET the result at another URL, given in Location.
The usual reply after a form POST, so a reload does not submit the form again (the Post/Redirect/Get pattern).
Class
3xx · Redirection
Defined in
RFC 9110 §15.4.4
Headers
Location
304Not Modified
The copy the client already has is still current; use it.
The answer to a conditional GET (If-None-Match or If-Modified-Since). It has no body, which is what saves the bandwidth.
Class
3xx · Redirection
Defined in
RFC 9110 §15.4.5
Headers
ETag, If-None-Match, If-Modified-Since, Last-Modified
305Use ProxyDon’t use
Deprecated. It once told the client to repeat the request through a proxy.
Deprecated for security reasons: a response should not be able to redirect traffic through a proxy of its choosing.
Class
3xx · Redirection
Defined in
RFC 9110 §15.4.6
306(Unused)Don’t use
Reserved. It was used in an earlier draft and is no longer used.
Never send it.
Class
3xx · Redirection
Defined in
RFC 9110 §15.4.7
307Temporary Redirect
The resource is temporarily at the URL in Location, and the client must repeat the request with the same method and body.
The safe temporary redirect for APIs: a POST stays a POST. Browsers also use an internal 307 when HSTS upgrades http:// to https://.
Class
3xx · Redirection
Defined in
RFC 9110 §15.4.8
Headers
Location
308Permanent Redirect
The resource has moved permanently to the URL in Location, and the method and body must be kept.
The method-preserving version of 301. Cacheable by default, like 301.
Class
3xx · Redirection
Defined in
RFC 9110 §15.4.9
Headers
Location
Caching
Cacheable by default unless headers say otherwise (RFC 9110 §15.1)
400Bad Request
The server can’t or won’t process the request because of something the client got wrong.
Malformed syntax, an invalid header, a body that isn’t valid JSON. Say what was wrong in the body — a bare 400 is hard to debug.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.1
401Unauthorized
The request has no valid credentials. Despite the name, it means unauthenticated.
The server must send a WWW-Authenticate header saying how to authenticate. An expired or missing token is a 401; a valid user without permission is a 403.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.2
Headers
WWW-Authenticate, Authorization
402Payment Required
Reserved for future use.
No standard meaning. Some APIs use it for an exhausted plan or failed payment, but clients can’t rely on that.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.3
403Forbidden
The server understood who you are and still refuses.
Logging in again will not help. A server that doesn’t want to reveal that the resource exists may send 404 instead.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.4
404Not Found
There is nothing at this URL, or the server won’t say whether there is.
It doesn’t say whether the absence is temporary or permanent — use 410 when a resource is gone for good. Cacheable by default.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.5
Caching
Cacheable by default unless headers say otherwise (RFC 9110 §15.1)
405Method Not Allowed
The URL exists but doesn’t support this method, such as a POST to a read-only resource.
The server must send an Allow header listing the methods it does support.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.6
Headers
Allow
Caching
Cacheable by default unless headers say otherwise (RFC 9110 §15.1)
406Not Acceptable
The server has no version of the resource that matches the client’s Accept headers.
For example, the client asked only for XML and the server can only produce JSON. Many servers send their default instead.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.7
Headers
Accept, Accept-Language, Accept-Encoding
407Proxy Authentication Required
Like 401, but the proxy between you and the server wants credentials.
The proxy sends Proxy-Authenticate; the client answers with Proxy-Authorization. Common on corporate networks.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.8
Headers
Proxy-Authenticate, Proxy-Authorization
408Request Timeout
The server gave up waiting for the client to finish sending the request.
The server closes the connection. The client may send the request again on a new connection.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.9
Headers
Connection
409Conflict
The request conflicts with the current state of the resource.
Typical for edit conflicts (someone else saved first) and duplicates, such as signing up with an email that is already registered. Explain the conflict so the user can resolve it.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.10
410Gone
The resource used to be here and has been removed on purpose, for good.
A stronger 404: search engines drop the URL sooner. Cacheable by default.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.11
Caching
Cacheable by default unless headers say otherwise (RFC 9110 §15.1)
411Length Required
The server won’t accept the request without a Content-Length header.
Send the body’s length, or use chunked transfer where the server accepts it.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.12
Headers
Content-Length
412Precondition Failed
A condition in the request headers, such as If-Match, was false.
Used for safe updates: the client says “only save if the ETag is still X”, and gets 412 if someone else has changed it since.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.13
Headers
If-Match, If-Unmodified-Since, ETag
413Content Too Large
The request body is larger than the server will accept. Formerly “Payload Too Large”.
Often an upload limit in nginx (client_max_body_size) or PHP (upload_max_filesize, post_max_size) rather than in your code. May carry Retry-After if the limit is temporary.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.14
Headers
Retry-After
414URI Too Long
The URL is longer than the server will read.
Usually a GET that should have been a POST, or a redirect loop that keeps appending to the query string. Cacheable by default.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.15
Caching
Cacheable by default unless headers say otherwise (RFC 9110 §15.1)
415Unsupported Media Type
The server doesn’t accept the body’s format.
Check the Content-Type header — sending JSON without Content-Type: application/json is a common cause.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.16
Headers
Content-Type, Accept, Accept-Encoding
416Range Not Satisfiable
The Range asked for lies outside the resource, for example beyond the end of the file.
Send Content-Range: bytes */<length> so the client learns the real size.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.17
Headers
Range, Content-Range
417Expectation Failed
The server can’t meet the Expect header, such as Expect: 100-continue.
Retry without the Expect header.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.18
Headers
Expect
418(Unused)
Reserved. Known as “I’m a teapot” from an April Fools’ RFC (RFC 2324).
RFC 9110 reserves it because it is deployed as a joke, so it can’t be assigned a real meaning. Don’t send it from a real API.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.19
421Misdirected Request
The request reached a server that can’t produce a response for that host.
Happens when HTTP/2 or HTTP/3 reuses a connection for another hostname the certificate covers but the server doesn’t serve. The client should retry on a new connection.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.20
422Unprocessable Content
The body is well-formed but its contents are invalid — for example valid JSON with an impossible date.
The common choice for validation errors. Formerly “Unprocessable Entity” (WebDAV, RFC 4918).
Class
4xx · Client error
Defined in
RFC 9110 §15.5.21
423Locked
WebDAV: the resource is locked.
Someone else holds a lock on the file or folder.
Class
4xx · Client error
Defined in
RFC 4918 §11.3
424Failed Dependency
WebDAV: this action failed because another action it depended on failed.
Seen inside Multi-Status responses.
Class
4xx · Client error
Defined in
RFC 4918 §11.4
425Too Early
The server won’t process a request sent in TLS early data, because it could be replayed.
The client should retry once the TLS handshake has completed.
Class
4xx · Client error
Defined in
RFC 8470 §5.2
426Upgrade Required
The server refuses this protocol and names the one to switch to in Upgrade.
For example, a service that only speaks a newer protocol version.
Class
4xx · Client error
Defined in
RFC 9110 §15.5.22
Headers
Upgrade
428Precondition Required
The server requires the request to be conditional, such as with If-Match.
Prevents the “lost update” problem: the client must prove it is editing the latest version.
Class
4xx · Client error
Defined in
RFC 6585 §3
Headers
If-Match
429Too Many Requests
The client has sent too many requests in a given time — rate limiting.
Send Retry-After with the wait in seconds. Clients should back off and retry, ideally with exponential backoff and jitter.
Class
4xx · Client error
Defined in
RFC 6585 §4
Headers
Retry-After
431Request Header Fields Too Large
A header, or all headers together, are too large.
Very often oversized cookies. Clearing the site’s cookies usually fixes it for a visitor.
Class
4xx · Client error
Defined in
RFC 6585 §5
444No ResponseNot standard
nginx closed the connection without sending anything.
Only ever appears in nginx’s own logs (return 444;), usually to drop unwanted traffic. The client never sees this number.
Class
4xx · Client error
Defined in
nginx only — not in the IANA registry
451Unavailable For Legal Reasons
The server is denying access because of a legal demand, such as a court order or government block.
The number is a reference to Fahrenheit 451. The response should explain the demand and who made it.
Class
4xx · Client error
Defined in
RFC 7725 §3
499Client Closed RequestNot standard
nginx logged that the client gave up before the response was ready.
The visitor closed the tab, or a client timeout fired first. Often a sign the upstream is slow.
Class
4xx · Client error
Defined in
nginx only — not in the IANA registry
500Internal Server Error
Something went wrong on the server that it has no more specific code for.
Usually an unhandled exception. The server log has the real error; the response should not leak stack traces.
Class
5xx · Server error
Defined in
RFC 9110 §15.6.1
501Not Implemented
The server doesn’t support the functionality needed, such as an unrecognised method.
Unlike 405, the method isn’t supported anywhere on this server. Cacheable by default.
Class
5xx · Server error
Defined in
RFC 9110 §15.6.2
Caching
Cacheable by default unless headers say otherwise (RFC 9110 §15.1)
502Bad Gateway
A gateway or proxy got an invalid response from the server behind it.
The app server crashed, isn’t running, or closed the connection — check it, not the proxy (nginx, a load balancer, a CDN).
Class
5xx · Server error
Defined in
RFC 9110 §15.6.3
503Service Unavailable
The server can’t handle the request right now — overloaded or down for maintenance.
A temporary state. Send Retry-After when you know how long; search engines treat a short 503 as “come back later” rather than “gone”.
Class
5xx · Server error
Defined in
RFC 9110 §15.6.4
Headers
Retry-After
504Gateway Timeout
A gateway or proxy didn’t get a response from the server behind it in time.
The upstream is too slow — a long query, a stuck job. Raise the proxy timeout only after making the work faster or asynchronous (202).
Class
5xx · Server error
Defined in
RFC 9110 §15.6.5
505HTTP Version Not Supported
The server doesn’t support the HTTP version used in the request.
Rare in practice.
Class
5xx · Server error
Defined in
RFC 9110 §15.6.6
506Variant Also Negotiates
A server configuration error in transparent content negotiation.
The chosen variant is itself set up to negotiate, which would loop.
Class
5xx · Server error
Defined in
RFC 2295 §8.1
507Insufficient Storage
WebDAV: the server can’t store what is needed to complete the request.
The disk or quota is full.
Class
5xx · Server error
Defined in
RFC 4918 §11.5
508Loop Detected
WebDAV: the server found an infinite loop while processing the request.
Usually a binding that points back at one of its own parents.
Class
5xx · Server error
Defined in
RFC 5842 §7.2
510Not ExtendedDon’t use
An HTTP extension the request needs isn’t supported.
The IETF moved RFC 2774 to Historic status in 2022, and the registry marks the code obsoleted. Don’t send it.
Class
5xx · Server error
Defined in
RFC 2774 §7
511Network Authentication Required
You need to sign in to the network — a captive portal, as on hotel or airport Wi-Fi.
Sent by the network, not the site you asked for. Opening any page in a browser usually shows the sign-in page.
Class
5xx · Server error
Defined in
RFC 6585 §6
520Web Server Returned an Unknown ErrorNot standard
Cloudflare got an empty, unknown or unexpected response from the origin server.
Check the origin: crashes, oversized headers, or a connection reset.
Class
5xx · Server error
Defined in
Cloudflare only — not in the IANA registry
521Web Server Is DownNot standard
The origin server refused Cloudflare’s connection.
The web server isn’t running, or a firewall blocks Cloudflare’s IP ranges.
Class
5xx · Server error
Defined in
Cloudflare only — not in the IANA registry
522Connection Timed OutNot standard
Cloudflare couldn’t open a TCP connection to the origin in time.
The origin is overloaded, unreachable, or dropping Cloudflare’s packets.
Class
5xx · Server error
Defined in
Cloudflare only — not in the IANA registry
523Origin Is UnreachableNot standard
Cloudflare can’t reach the origin at all — often a wrong DNS record.
Check the origin IP address in the DNS settings.
Class
5xx · Server error
Defined in
Cloudflare only — not in the IANA registry
524A Timeout OccurredNot standard
Cloudflare connected to the origin but got no HTTP response within its time limit (100 seconds by default).
A slow request on the origin. Make long work asynchronous rather than holding the request open.
Class
5xx · Server error
Defined in
Cloudflare only — not in the IANA registry
525SSL Handshake FailedNot standard
Cloudflare couldn’t complete a TLS handshake with the origin.
The origin has no certificate, or supports no cipher Cloudflare offers.
Class
5xx · Server error
Defined in
Cloudflare only — not in the IANA registry
526Invalid SSL CertificateNot standard
Cloudflare couldn’t validate the origin’s certificate (Full (strict) mode).
The certificate is expired, self-signed, or for another hostname.
Class
5xx · Server error
Defined in
Cloudflare only — not in the IANA registry

Runs in your browser — nothing you enter leaves this device.

About this tool

What it does

Every HTTP response starts with a three-digit status code that says how the request went: 2xx it worked, 3xx look elsewhere, 4xx the request was wrong, 5xx the server failed. This reference lists every code in the IANA registry with a plain explanation, when a server should send it, the headers that go with it, and the exact document and section that defines it — mostly RFC 9110, the current HTTP standard — so you can check the wording at source. Codes you will meet in logs but that no standard defines, such as nginx’s 499 and Cloudflare’s 520–526, are included too and clearly marked as vendor codes. It also explains the pairs people mix up, such as 401 and 403, or 301 and 308.

How to use it

Type a code such as 429 to open it, or the first digits (50) or a class (4xx) to narrow the list.
Or describe what happened — “rate limit”, “timeout”, “redirect permanent”, “captive portal” — and the closest codes come first.
Use the class buttons to see only informational, success, redirection, client or server errors.
Open any code for its meaning, when to use it, its headers, whether it is cacheable by default, and where it is defined.
Check “Often confused” when choosing between two codes for an API.

Limits and your data

This describes what the standards say. Real servers and frameworks do not always follow them — plenty of APIs return 200 with an error in the body, or 400 for every problem.
Vendor codes (444, 499, 520–526) mean something only on the software that sends them. Another product may use the same number differently.
It is a reference, not a checker: it does not request a URL to see what status it returns.
The list was checked against the IANA registry on 24 September 2026. New codes are rare, but the registry is the authority.
The whole list is part of the page. Searching happens in your browser, and nothing you type is sent anywhere or stored.

Questions

What is the difference between 401 and 403?

401 Unauthorized means the server does not know who you are — the credentials are missing, wrong or expired, and logging in may help. 403 Forbidden means it knows who you are and you still are not allowed. A 401 must carry a WWW-Authenticate header saying how to authenticate.

Should an API return 400 or 422 for validation errors?

Use 400 when the request cannot be parsed at all — broken JSON, a missing required header. Use 422 Unprocessable Content when the request is well-formed but the values are wrong, like an end date before a start date. Either way, say in the body which field failed and why.

What is the difference between 301, 302, 307 and 308?

301 and 308 are permanent; 302 and 307 are temporary. The difference within each pair is the method: with 307 and 308 the client must repeat a POST as a POST, while with 301 and 302 clients have historically switched to GET. For a redirect after a form submission, 303 See Other deliberately switches to GET.

What causes 502 Bad Gateway and 504 Gateway Timeout?

Both come from a proxy, load balancer or CDN in front of your application. 502 means the application answered with something invalid or dropped the connection — it may have crashed or not be running. 504 means it did not answer in time. In both cases look at the application server, not the proxy.

Is 418 I’m a teapot a real status code?

It began as an April Fools’ joke in RFC 2324 (1998). RFC 9110 now lists 418 as reserved and unused, precisely because so much software sends it as a joke, so it can never be given a real meaning. Do not use it in a real API.

Which responses can be cached without cache headers?

RFC 9110 §15.1 lists the codes that are cacheable by default when no header says otherwise: 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414 and 501. A cache may then choose a lifetime itself, which is why a mistaken 301 can stick in browsers for a long time.