HTTP Status Codes

All 63 registered codes, searchable, plus the ones servers invented.

Searcha number or a word

Class

Registered with the IANA only

Matches: 84
Registered: 63
Unofficial: 21
In the registry: 63

100Continue
1xx InformationalRFC 9110IANA registry
The server has read the request headers and is willing to receive the body. A client that sent an Expect header waits for this line before uploading anything.
When to return it. Emitted by the server itself when a client asks permission before sending a large body.
The common mistake. Not something you write by hand. A client that never sent Expect will never see it.
101Switching Protocols
1xx InformationalRFC 9110IANA registry
The connection is being handed over to the protocol named in the Upgrade header. After this line the bytes on the socket stop being HTTP.
When to return it. On a successful WebSocket handshake, or any other upgrade the server agrees to.
The common mistake. HTTP/2 dropped the upgrade mechanism, so a 101 only ever appears over HTTP/1.1.
102Processing
1xx InformationalRFC 2518IANA registry
A WebDAV holding line that says the request is still being worked on. It carries no information beyond still alive.
When to return it. Long-running WebDAV operations that would otherwise trip a client timeout.
The common mistake. Defined in the original WebDAV RFC and quietly dropped from its replacement. Prefer 103.
103Early Hints
1xx InformationalRFC 8297IANA registry
A preliminary response carrying Link headers so the browser can start preloading before the real response exists. The final status still arrives afterwards.
When to return it. When the server knows which stylesheets and fonts the page will need but has not finished rendering it.
The common mistake. Some intermediaries still mangle it, and a client that mishandles it treats the hints as the answer.
200OK
2xx SuccessfulRFC 9110IANA registry
The request succeeded and the body is the result. What the result means depends on the method: the resource for GET, a description of the outcome for POST.
When to return it. Any successful request that has something to send back.
The common mistake. Returning 200 with an error object inside is the classic API mistake. Caches, retries and monitoring read the status line, not your JSON.
201Created
2xx SuccessfulRFC 9110IANA registry
A new resource exists because of this request, and the Location header says where. The body usually describes what was created.
When to return it. After a POST or a PUT that brought a resource into existence.
The common mistake. A 201 without a Location header makes the client guess the URL it has just created.
202Accepted
2xx SuccessfulRFC 9110IANA registry
The request was valid and queued, but nothing has happened yet. The response is a promise, not a result.
When to return it. Asynchronous work: a job accepted now and run later.
The common mistake. Failure can never be reported through the status line afterwards, so give the client a URL to poll.
203Non-Authoritative Information
2xx SuccessfulRFC 9110IANA registry
A 200 that some proxy modified in transit. The payload is a transformed copy, not what the origin sent.
When to return it. By a transforming proxy that rewrote the body it was relaying.
204No Content
2xx SuccessfulRFC 9110IANA registry
The request succeeded and there is deliberately nothing to send back. The response ends with the headers.
When to return it. A DELETE that worked, or a PUT whose result the client already holds.
The common mistake. A 204 must carry no body at all. Send bytes after the headers and strict clients hang or error.
205Reset Content
2xx SuccessfulRFC 9110IANA registry
The request succeeded and the client should clear the form that sent it. Like 204, it carries no body.
When to return it. Data-entry screens meant to be filled in again immediately.
206Partial Content
2xx SuccessfulRFC 9110IANA registry
Only the requested byte range is being returned, described by Content-Range. Video scrubbing and resumable downloads are built on it.
When to return it. In answer to a valid Range request.
The common mistake. Answering a Range request with a plain 200 is legal but drags the whole file down the wire again.
207Multi-Status
2xx SuccessfulRFC 4918IANA registry
One response carrying a different status for each of several resources. The real outcomes live in the XML body.
When to return it. WebDAV operations that touch a whole collection.
The common mistake. The outer status is always 207, so a client reading only the status line sees success when all of it failed.
208Already Reported
2xx SuccessfulRFC 5842IANA registry
A member of a WebDAV collection was already listed earlier in this same response. It exists to avoid repeating large sub-trees.
When to return it. Inside a 207 body, for bindings already enumerated.
226IM Used
2xx SuccessfulRFC 3229IANA registry
The response is the result of applying one or more instance manipulations, such as a delta, to the current resource. Almost nothing implements it.
When to return it. Delta encoding negotiated through the A-IM request header.
300Multiple Choices
3xx RedirectionRFC 9110IANA registry
More than one representation exists and the server refuses to choose. The body is meant to list the options.
When to return it. Agent-driven negotiation, which almost nobody implements.
301Moved Permanently
3xx RedirectionRFC 9110IANA registry
The resource has a new URL for good, and caches and search engines are expected to remember it. Old links should be rewritten.
When to return it. Domain moves, HTTPS migrations, permanent restructures.
The common mistake. Clients have always been allowed to turn the follow-up request into a GET. If the method must survive, use 308.
302Found
3xx RedirectionRFC 9110IANA registry
A temporary redirect that, in practice, turns the follow-up request into a GET. The original URL stays canonical.
When to return it. Post-redirect-get flows and temporary detours.
The common mistake. The spec says the method should be preserved and every browser ignores that. 303 and 307 exist because of it.
303See Other
3xx RedirectionRFC 9110IANA registry
The result of the request is at another URL and must be fetched with GET. It is the one redirect where changing the method is intentional.
When to return it. After a POST, to send the browser to a result page that survives a refresh.
304Not Modified
3xx RedirectionRFC 9110IANA registry
The copy the client already holds is still fresh, so no body is sent. It only ever answers a conditional request.
When to return it. When If-None-Match matches the current ETag, or the resource is older than If-Modified-Since.
The common mistake. A 304 must have no body and must still repeat the headers a cache needs to update its entry.
305Use Proxy
3xx RedirectionRFC 9110IANA registry
Obsolete. It told a client to repeat the request through a named proxy, which turned out to be a neat way to hijack traffic.
When to return it. Never. Clients are required to ignore it.
306(Unused)
3xx RedirectionRFC 9110IANA registry
Reserved and empty. It was defined in a draft, withdrawn before publication, and the number was never reissued.
When to return it. Never.
307Temporary Redirect
3xx RedirectionRFC 9110IANA registry
Like 302, except the method and the body must be repeated exactly. A POST stays a POST.
When to return it. Temporary moves where rewriting the request as a GET would break it.
308Permanent Redirect
3xx RedirectionRFC 9110IANA registry
Like 301, except the method and the body must be preserved. It is the permanent redirect an API should use.
When to return it. Permanent moves of endpoints that accept POST, PUT or PATCH.
The common mistake. Clients older than 2015 may not understand it. Every current browser does.
400Bad Request
4xx Client ErrorRFC 9110IANA registry
The server cannot process the request because something about it is malformed. It is the generic client error, not a verdict on your data.
When to return it. Broken syntax, an unparsable body, a header that cannot be read.
The common mistake. Using 400 for business-rule failures loses the difference between I cannot read this and I read it and disagree. The second one is 422.
401Unauthorized
4xx Client ErrorRFC 9110IANA registry
Authentication is missing or invalid, and the response must say how to authenticate through WWW-Authenticate. Retrying with credentials may work.
When to return it. No token, an expired token, a wrong password.
The common mistake. It means unauthenticated, despite the name. If you already know who is asking and still refuse, the honest code is 403.
402Payment Required
4xx Client ErrorRFC 9110IANA registry
Reserved since the first HTTP specification and never standardised. Several APIs use it for billing failures anyway.
When to return it. By convention only, for an unpaid or exhausted plan.
403Forbidden
4xx Client ErrorRFC 9110IANA registry
The server understood the request, knows who is asking, and refuses. Authenticating again will not change the answer.
When to return it. A known user reaching for something outside their permissions.
The common mistake. A 403 confirms the resource exists. When even its existence is private, 404 is the safer answer.
404Not Found
4xx Client ErrorRFC 9110IANA registry
There is nothing at this URL, and the server will not say whether there ever was. The vagueness is deliberate.
When to return it. Unknown paths, and deleted resources whose history you do not want to disclose.
The common mistake. A not-found page served with a 200 status is a soft 404: invisible to crawlers and to your own alerting.
405Method Not Allowed
4xx Client ErrorRFC 9110IANA registry
The URL exists but not for this verb. The Allow header must list the verbs that do work.
When to return it. A POST to a read-only endpoint.
The common mistake. Omitting Allow makes the response unactionable, and technically invalid.
406Not Acceptable
4xx Client ErrorRFC 9110IANA registry
Nothing the server can produce matches the Accept headers the client sent. Negotiation failed outright.
When to return it. A client demanding a representation you simply do not have.
The common mistake. Most servers ignore this and send their default type instead, which the spec allows and users prefer.
407Proxy Authentication Required
4xx Client ErrorRFC 9110IANA registry
Like 401, except the challenge comes from a proxy rather than the origin. Credentials travel in Proxy-Authorization.
When to return it. Corporate proxies that authenticate before forwarding anything.
408Request Timeout
4xx Client ErrorRFC 9110IANA registry
The client opened a connection and did not finish sending the request in time, so the server is closing it. Nothing was processed.
When to return it. Idle connections and stalled uploads.
The common mistake. Easily confused with 504, which is about a slow upstream rather than a slow client.
409Conflict
4xx Client ErrorRFC 9110IANA registry
The request is valid but collides with the current state of the resource. The body should say what needs reconciling.
When to return it. Edit conflicts, duplicate unique keys, a state machine in the wrong state.
410Gone
4xx Client ErrorRFC 9110IANA registry
The resource existed and is intentionally gone for good. It is a stronger and more useful statement than 404.
When to return it. Retired endpoints and content removed on purpose.
The common mistake. Search engines drop a 410 faster than a 404. That is the point, and also the risk of using it by accident.
411Length Required
4xx Client ErrorRFC 9110IANA registry
The request arrived without a Content-Length and this server insists on one. Resend with the length declared.
When to return it. Servers that refuse chunked uploads.
412Precondition Failed
4xx Client ErrorRFC 9110IANA registry
A condition the client attached to the request was false, so nothing was done. It is the safe half of optimistic concurrency.
When to return it. An If-Match against an ETag that has already moved on.
413Content Too Large
4xx Client ErrorRFC 9110IANA registry
The body is larger than the server will accept. RFC 9110 renamed it from Payload Too Large.
When to return it. Upload size limits.
The common mistake. The limit usually lives in the reverse proxy, not your application, so the error page will not be yours.
414URI Too Long
4xx Client ErrorRFC 9110IANA registry
The request target exceeds what the server is willing to parse. It is almost always a GET that should have been a POST.
When to return it. Query strings assembled in a loop.
415Unsupported Media Type
4xx Client ErrorRFC 9110IANA registry
The body arrived in a format this endpoint does not accept. It is about Content-Type, the header you sent.
When to return it. Form data posted to a JSON-only endpoint.
The common mistake. The mirror image of 406: 415 judges what you sent, 406 judges what you asked for.
416Range Not Satisfiable
4xx Client ErrorRFC 9110IANA registry
The requested byte range lies outside the resource. The response should say how long the resource actually is.
When to return it. A resumed download of a file that changed size in the meantime.
417Expectation Failed
4xx Client ErrorRFC 9110IANA registry
The server will not meet the expectation stated in the Expect header. In practice that always means the continue handshake.
When to return it. Proxies that refuse to relay a 100-continue exchange.
418(Unused)
4xx Client ErrorRFC 9110IANA registry
Registered only to keep the number blocked: it comes from the 1998 April Fools coffee-pot protocol, where it meant I am a teapot. RFC 9110 reserves it so nobody can ever allocate it for something real.
When to return it. Never in earnest, which has not stopped a dozen frameworks from shipping a helper for it.
The common mistake. The joke is now permanent. Treating a teapot response as meaningful is a bug, not a feature.
419Page Expired
4xx Client ErrorLaravelUnofficial
Laravel returns this when the CSRF token in a form no longer matches the session. The session expired while the page sat open.
When to return it. Emitted by the framework, not by you.
The common mistake. Reads like a 4xx about the page. It is really about the token, so reloading the form fixes it.
420Enhance Your Calm
4xx Client ErrorTwitter API v1Unofficial
The rate-limit code of the old Twitter API, retired when 429 was standardised. Spring once used the same number for Method Failure.
When to return it. Never. Use 429.
The common mistake. Two products used 420 for unrelated things, so the number tells you nothing on its own.
421Misdirected Request
4xx Client ErrorRFC 9110IANA registry
The connection reached a server that cannot serve this authority. Under HTTP/2 connection coalescing that happens more often than you would expect.
When to return it. A shared certificate pointing several hostnames at different backends.
422Unprocessable Content
4xx Client ErrorRFC 9110IANA registry
The syntax is fine and the content is wrong. It is the code for validation failures that 400 keeps being abused for.
When to return it. A well-formed JSON body whose fields break your rules.
The common mistake. RFC 9110 moved it from WebDAV into core HTTP, so references calling it WebDAV-only are out of date.
423Locked
4xx Client ErrorRFC 4918IANA registry
The resource is locked and the request cannot proceed until the lock goes. WebDAV only.
When to return it. A locked WebDAV resource or one of its members.
424Failed Dependency
4xx Client ErrorRFC 4918IANA registry
The request failed because an earlier request it depended on failed. Nothing here was even attempted.
When to return it. Inside WebDAV batches where one member already failed.
425Too Early
4xx Client ErrorRFC 8470IANA registry
The request arrived in TLS 1.3 early data and the server will not risk processing something replayable. Resend once the handshake finishes.
When to return it. Non-idempotent requests that a client sent as 0-RTT data.
426Upgrade Required
4xx Client ErrorRFC 9110IANA registry
The server refuses this request on this protocol version and names an alternative in the Upgrade header. The request may succeed after switching.
When to return it. Forcing TLS, or a newer protocol version, on an old client.
428Precondition Required
4xx Client ErrorRFC 6585IANA registry
The server insists the request be conditional, to stop blind overwrites. Add If-Match and try again.
When to return it. APIs that require optimistic concurrency on every write.
429Too Many Requests
4xx Client ErrorRFC 6585IANA registry
The client has sent too many requests inside a window and is being throttled. Retry-After should say how long to wait.
When to return it. Rate limiting, per API key or per address.
The common mistake. A 429 without Retry-After invites the client to hammer you harder. The header is what makes the code useful.
430Shopify Security Rejection
4xx Client ErrorShopifyUnofficial
Shopify returns this when its edge decides a request looks malicious. The storefront never sees it.
When to return it. Emitted by the platform.
431Request Header Fields Too Large
4xx Client ErrorRFC 6585IANA registry
The headers, or one of them, exceed what the server will accept. An oversized cookie is the usual culprit.
When to return it. Cookie accumulation on a long-lived domain.
440Login Time-out
4xx Client ErrorMicrosoft IISUnofficial
The session expired and IIS wants the client to authenticate again. Roughly a 401 with a story attached.
When to return it. Emitted by IIS.
444No Response
4xx Client ErrornginxUnofficial
An internal nginx code that closes the connection without sending anything. It never travels over the wire.
When to return it. In an nginx config, to drop a request silently.
The common mistake. It appears in the access log and nowhere else, which is why it confuses people reading logs.
450Blocked by Windows Parental Controls
4xx Client ErrorMicrosoftUnofficial
Windows returns this when parental controls block the address. The site itself is untouched.
When to return it. Emitted by the operating system.
451Unavailable For Legal Reasons
4xx Client ErrorRFC 7725IANA registry
The content is withheld because of a legal demand, and the response should identify who demanded it. The number is a deliberate nod to Fahrenheit 451.
When to return it. Court orders, statutory blocks, takedowns imposed by law.
494Request Header Too Large
4xx Client ErrornginxUnofficial
nginx logs this before the standard 431 existed for the same condition. Also internal.
When to return it. Emitted by nginx.
495SSL Certificate Error
4xx Client ErrornginxUnofficial
The client certificate failed verification. nginx uses the 49x block for TLS problems that HTTP has no code for.
When to return it. Emitted by nginx during mutual TLS.
497HTTP Request Sent to HTTPS Port
4xx Client ErrornginxUnofficial
A plaintext request arrived on a TLS listener. nginx answers in plaintext so the mistake is visible.
When to return it. Emitted by nginx.
The common mistake. Usually a hard-coded http:// in a client, not a server misconfiguration.
498Invalid Token
4xx Client ErrorEsri ArcGISUnofficial
Esri servers use this for an expired or malformed token. 401 covers the same ground.
When to return it. Emitted by ArcGIS.
499Client Closed Request
4xx Client ErrornginxUnofficial
The client hung up before nginx could answer. It is the single most misread line in an nginx log.
When to return it. Logged by nginx, never sent.
The common mistake. A spike of 499s is a symptom of your own slowness, not of misbehaving clients.
500Internal Server Error
5xx Server ErrorRFC 9110IANA registry
Something failed on the server and it has nothing more specific to say. It is the code an unhandled exception produces.
When to return it. Genuine bugs, and nothing the client could have fixed.
The common mistake. Returning 500 for bad input trains your own alerting to ignore the graph that matters.
501Not Implemented
5xx Server ErrorRFC 9110IANA registry
The server does not support the method at all, for any resource. It is a statement about capability, not permission.
When to return it. A verb the server does not recognise.
The common mistake. For a method this particular URL does not accept, the right answer is 405.
502Bad Gateway
5xx Server ErrorRFC 9110IANA registry
A proxy received an invalid response from the server behind it. The failure is upstream of whatever answered you.
When to return it. By load balancers when the origin crashes or speaks nonsense.
503Service Unavailable
5xx Server ErrorRFC 9110IANA registry
The server is temporarily unable to handle the request, usually because it is overloaded or in maintenance. It promises the condition is temporary.
When to return it. Deploys, load shedding, planned downtime.
The common mistake. Pair it with Retry-After. That header is what stops a search engine reading an hour of maintenance as a removal.
504Gateway Timeout
5xx Server ErrorRFC 9110IANA registry
A proxy gave up waiting for the server behind it. Your request may still be running upstream.
When to return it. Slow backends sitting behind a gateway with a shorter timeout.
The common mistake. It does not mean the work failed. A 504 on a POST can leave a half-finished side effect behind.
505HTTP Version Not Supported
5xx Server ErrorRFC 9110IANA registry
The server refuses the major HTTP version used in the request. It should say which versions it does support.
When to return it. Rare, and almost always a misconfigured client or a broken intermediary.
506Variant Also Negotiates
5xx Server ErrorRFC 2295IANA registry
A misconfiguration: the variant that was chosen is itself a negotiating resource, so negotiation loops. Nothing can be served.
When to return it. Transparent content negotiation that has gone circular.
507Insufficient Storage
5xx Server ErrorRFC 4918IANA registry
The server cannot store the representation needed to complete the request. Disk, quota, or both.
When to return it. WebDAV writes against a full store.
508Loop Detected
5xx Server ErrorRFC 5842IANA registry
The server gave up because the operation was walking in circles. WebDAV bindings can form genuine cycles.
When to return it. Infinite-depth WebDAV traversals.
509Bandwidth Limit Exceeded
5xx Server ErrorApache and cPanelUnofficial
Shared hosting returns this when an account blows through its monthly transfer allowance. It is a billing state, not a protocol one.
When to return it. Emitted by the hosting panel.
510Not Extended
5xx Server ErrorRFC 2774IANA registry
The request needs an extension the server does not have. The experiment behind it never went anywhere.
When to return it. Never, in practice.
511Network Authentication Required
5xx Server ErrorRFC 6585IANA registry
The client must log in to the network before the request can go anywhere. A captive portal sends this, never the origin server.
When to return it. Hotel and airport Wi-Fi that intercepts traffic until you accept the terms.
The common mistake. It exists so portals stop forging 200 responses, which is what breaks every non-browser client.
520Web Server Returned an Unknown Error
5xx Server ErrorCloudflareUnofficial
Cloudflare reached your origin and could not make sense of the answer. It is the catch-all of the 52x family.
When to return it. Emitted by Cloudflare.
The common mistake. A 520 is about your origin, not about Cloudflare, however much the branded page suggests otherwise.
521Web Server Is Down
5xx Server ErrorCloudflareUnofficial
The origin refused the connection outright. Usually the process is not running, or a firewall is blocking Cloudflare.
When to return it. Emitted by Cloudflare.
522Connection Timed Out
5xx Server ErrorCloudflareUnofficial
The TCP handshake with the origin never completed. Packets are being dropped somewhere between the edge and you.
When to return it. Emitted by Cloudflare.
523Origin Is Unreachable
5xx Server ErrorCloudflareUnofficial
Cloudflare cannot route to the origin at all. Usually a DNS record pointing at an address that no longer exists.
When to return it. Emitted by Cloudflare.
524A Timeout Occurred
5xx Server ErrorCloudflareUnofficial
The connection succeeded and the origin took longer than 100 seconds to answer. The request is still running back there.
When to return it. Emitted by Cloudflare.
The common mistake. The proxy timeout is not configurable on the lower plans, so long jobs need a queue rather than a longer wait.
525SSL Handshake Failed
5xx Server ErrorCloudflareUnofficial
The TLS handshake between the edge and the origin failed. Cipher mismatch or an origin certificate the edge will not accept.
When to return it. Emitted by Cloudflare.
526Invalid SSL Certificate
5xx Server ErrorCloudflareUnofficial
The origin certificate could not be validated in Full (strict) mode. Expired, self-signed, or for the wrong name.
When to return it. Emitted by Cloudflare.
530Site Frozen
5xx Server ErrorCloudflareUnofficial
Always accompanied by a second, more specific 1xxx error in the body. On its own it means nothing.
When to return it. Emitted by Cloudflare.
The common mistake. Reading the 530 without the 1xxx code underneath it is the mistake; the real cause is only in the body.
999Request Denied
Outside the valid rangeLinkedInUnofficial
LinkedIn returns this to clients it takes for scrapers. The number is outside the valid HTTP range entirely.
When to return it. Never. Status codes are three digits from 100 to 599.
The common mistake. Some HTTP libraries refuse to parse it, so a crawler can fail with a parse error rather than a status.

Everything runs in your browser. Nothing you type is sent to a server.

Found a bug in this tool? Report it.

Share this tool

Every HTTP status code, and what it actually commits you to

This page is a searchable list of HTTP status codes: type a number, or a word like teapot or redirect, and you get the name, the class, the RFC that defines it, when to return it and the mistake people make with it. Sixty-three codes are registered with the IANA. The rest of what you will meet in a log was invented by nginx, Cloudflare or a framework, and those are listed separately because pretending otherwise is how myths start.

The three digits are not decoration. They are the only part of a response that every cache, proxy, crawler, load balancer and retry library agrees on. Your JSON body is read by your own client; the status line is read by everything in between.

The five classes

The first digit is the contract, and it is the part you should get right even when the second and third are debatable.

1xx informational means the exchange is still going and nothing has been decided. 2xx successful means the request was received, understood and accepted — what arrives next depends on the method. 3xx redirection means the answer is elsewhere, and the code says whether the move is permanent and whether the method survives it. 4xx client error means the request itself is wrong, and repeating it unchanged will fail identically. 5xx server error means the request may have been perfectly good and the server failed anyway, which is the class that makes a retry reasonable.

Get the first digit wrong and you break automation you never wrote. A validation failure dressed as a 500 will page someone at three in the morning. A genuine outage dressed as a 200 will page nobody at all.

The pairs that get confused

401 and 403. 401 is unauthenticated, 403 is authenticated-and-refused. The names suggest the opposite, which is why this is the single most reversed pair in the list.

301 and 308. Both are permanent. Only 308 guarantees the method and body survive the hop, which is why an API endpoint should never move with a 301.

302, 303 and 307. 302 is what browsers actually do, not what the specification says; 303 forces a GET on purpose; 307 preserves the method on purpose. Two of the three exist only because 302 was implemented before it was defined.

400 and 422. 400 means the server could not read the request. 422 means it read it fine and the contents break a rule. Collapsing both into 400 throws away the distinction your client needs to decide whether retrying with different data could help.

204 and 200 with an empty body. A 204 must have no body at all, and that is a promise strict clients rely on. Sending zero bytes with a 200 and a Content-Length of 0 is a different thing.

408 and 504. 408 is a slow client; 504 is a slow upstream. They look alike in a dashboard and have opposite fixes.

The registered list

Sixty-three codes, exactly as the IANA registry has them, including the two reserved numbers (306 and 418) that exist only to stay empty.

Code	Name	Class	Spec
100	Continue	1xx	RFC 9110
101	Switching Protocols	1xx	RFC 9110
102	Processing	1xx	RFC 2518
103	Early Hints	1xx	RFC 8297
200	OK	2xx	RFC 9110
201	Created	2xx	RFC 9110
202	Accepted	2xx	RFC 9110
203	Non-Authoritative Information	2xx	RFC 9110
204	No Content	2xx	RFC 9110
205	Reset Content	2xx	RFC 9110
206	Partial Content	2xx	RFC 9110
207	Multi-Status	2xx	RFC 4918
208	Already Reported	2xx	RFC 5842
226	IM Used	2xx	RFC 3229
300	Multiple Choices	3xx	RFC 9110
301	Moved Permanently	3xx	RFC 9110
302	Found	3xx	RFC 9110
303	See Other	3xx	RFC 9110
304	Not Modified	3xx	RFC 9110
305	Use Proxy	3xx	RFC 9110
306	(Unused)	3xx	RFC 9110
307	Temporary Redirect	3xx	RFC 9110
308	Permanent Redirect	3xx	RFC 9110
400	Bad Request	4xx	RFC 9110
401	Unauthorized	4xx	RFC 9110
402	Payment Required	4xx	RFC 9110
403	Forbidden	4xx	RFC 9110
404	Not Found	4xx	RFC 9110
405	Method Not Allowed	4xx	RFC 9110
406	Not Acceptable	4xx	RFC 9110
407	Proxy Authentication Required	4xx	RFC 9110
408	Request Timeout	4xx	RFC 9110
409	Conflict	4xx	RFC 9110
410	Gone	4xx	RFC 9110
411	Length Required	4xx	RFC 9110
412	Precondition Failed	4xx	RFC 9110
413	Content Too Large	4xx	RFC 9110
414	URI Too Long	4xx	RFC 9110
415	Unsupported Media Type	4xx	RFC 9110
416	Range Not Satisfiable	4xx	RFC 9110
417	Expectation Failed	4xx	RFC 9110
418	(Unused)	4xx	RFC 9110
421	Misdirected Request	4xx	RFC 9110
422	Unprocessable Content	4xx	RFC 9110
423	Locked	4xx	RFC 4918
424	Failed Dependency	4xx	RFC 4918
425	Too Early	4xx	RFC 8470
426	Upgrade Required	4xx	RFC 9110
428	Precondition Required	4xx	RFC 6585
429	Too Many Requests	4xx	RFC 6585
431	Request Header Fields Too Large	4xx	RFC 6585
451	Unavailable For Legal Reasons	4xx	RFC 7725
500	Internal Server Error	5xx	RFC 9110
501	Not Implemented	5xx	RFC 9110
502	Bad Gateway	5xx	RFC 9110
503	Service Unavailable	5xx	RFC 9110
504	Gateway Timeout	5xx	RFC 9110
505	HTTP Version Not Supported	5xx	RFC 9110
506	Variant Also Negotiates	5xx	RFC 2295
507	Insufficient Storage	5xx	RFC 4918
508	Loop Detected	5xx	RFC 5842
510	Not Extended	5xx	RFC 2774
511	Network Authentication Required	5xx	RFC 6585

Codes that are not codes

Every one of these appears in real logs and none of them is registered. Most were invented by a single server or platform, and some never travel over the wire at all — nginx's 444 and 499 are log entries, not responses. LinkedIn's 999 is not even a valid status code, since HTTP defines three digits from 100 to 599; some client libraries refuse to parse it and fail with a protocol error instead of a status.

Code	Name	Source
419	Page Expired	Laravel
420	Enhance Your Calm	Twitter API v1
430	Shopify Security Rejection	Shopify
440	Login Time-out	Microsoft IIS
444	No Response	nginx
450	Blocked by Windows Parental Controls	Microsoft
494	Request Header Too Large	nginx
495	SSL Certificate Error	nginx
497	HTTP Request Sent to HTTPS Port	nginx
498	Invalid Token	Esri ArcGIS
499	Client Closed Request	nginx
509	Bandwidth Limit Exceeded	Apache and cPanel
520	Web Server Returned an Unknown Error	Cloudflare
521	Web Server Is Down	Cloudflare
522	Connection Timed Out	Cloudflare
523	Origin Is Unreachable	Cloudflare
524	A Timeout Occurred	Cloudflare
525	SSL Handshake Failed	Cloudflare
526	Invalid SSL Certificate	Cloudflare
530	Site Frozen	Cloudflare
999	Request Denied	LinkedIn

The practical rule: if you are choosing a code, choose a registered one. If you are reading a code, check this second table before searching for meaning that was never there. A 520 is not a Cloudflare problem — it is your origin returning something Cloudflare could not parse, and the branded error page is very good at implying otherwise.

Where this fits

Status codes are one third of an HTTP response; the other two are the headers and the body. When the part confusing you is the address rather than the answer, the URL parser breaks a request target into the pieces the server actually sees. When a 401 arrives and the token looks fine, the JWT decoder shows the expiry claim without sending the token anywhere. And when a 403 is coming from a network rule rather than an application one, the CIDR calculator is usually faster than reading the allow list by eye.

Everything on this page runs in your browser. Nothing you type is sent anywhere, because there is nowhere to send it: the whole table is in the page you already downloaded.

Frequently asked questions

What does a 429 mean, and what should I do about it?

You have been rate limited. The server accepted your credentials, understood the request, and is refusing it only because too many requests arrived inside its window. The useful part of the response is the Retry-After header, which gives either a number of seconds or an HTTP date; honour it instead of retrying immediately, and back off exponentially if it is missing. A 429 is not a bug in your request, so replaying the same call faster is the one reaction guaranteed to make things worse.

Is 418 a real HTTP status code?

It is a real registry entry and not a real status code, which is why it causes so much argument. The number comes from the Hyper Text Coffee Pot Control Protocol, an April Fools' joke published in 1998, where 418 meant the machine you asked to brew coffee is a teapot. RFC 9110 lists 418 as unused and reserves it permanently, precisely so a future extension cannot claim it. Plenty of frameworks ship a helper for it anyway. Sending one to a real client is a joke your monitoring will not get.

What is the difference between 401 and 403?

401 means the server does not know who you are; 403 means it does and still says no. The names are the wrong way round, which is the whole source of the confusion. A 401 must carry a WWW-Authenticate header describing how to authenticate, and retrying with valid credentials can succeed. A 403 is final for that identity, so a client that keeps retrying is wasting requests. There is a third option worth considering: when the existence of the resource is itself private, 404 leaks less than 403 does.

Should I use 301 or 308 for a permanent redirect?

Use 308 whenever the request might not be a GET. Both say the resource has moved for good, and both pass ranking signals, but clients have always been permitted to rewrite a 301 as a GET, and historically most of them did. That is harmless for a page and destructive for an API endpoint that accepts POST, because the body silently disappears. For plain page moves on a website, 301 is still the safer choice for old crawlers and proxies; for anything with a method and a body, 308 is the one that survives the hop.

Why is returning 200 with an error inside such a problem?

Because everything between your code and your user reads the status line and nothing else. A CDN will cache the failure, a retry library will treat it as success and stop retrying, a health check will report the service as healthy, and your error rate graph will stay flat through an outage. The body is for humans and for your own client; the status line is the interface every intermediary understands. If the request failed, say so in the three digits, then explain yourself in the body.

Related tools

Updated 5 September 2026