The Strange HTTP Status Codes: 451, 418, 420, 218 and 530, and What They Teach
Five odd status codes, which are standard, which are jokes and which are vendor inventions, and why custom codes are a trap for client code.
On this page
HTTP status codes look like a settled list until you meet one that is not on it. The odd ones are fun, and they also demonstrate exactly why the boring standard codes are worth the discipline.
451 Unavailable For Legal Reasons: the real one
Defined in RFC 7725 for cases where a server must refuse access because of a legal demand: a court order, a regulator, a takedown. The number is a deliberate reference to Ray Bradbury’s novel about censorship.
It exists because the alternatives lie. A blocked page returning 403 (forbidden) or 404 (not found) hides why, and users cannot tell censorship from a broken link. 451 makes the reason visible and machine-readable, and can point to who demanded it.
418 I’m a teapot: the joke that stuck
From RFC 2324, a deliberate April Fools’ specification for controlling coffee pots over HTTP, published in 1998. A teapot asked to brew coffee answers 418. It was never part of the actual HTTP standard, yet it became beloved enough that attempts to remove it from software have met resistance. Treat it as an Easter egg, not a feature: do not return it for real errors.
420 Enhance Your Calm: replaced by 429
Some early APIs used a made-up 420 to say “you are sending too many requests”. The standard answer arrived in RFC 6585 as 429 Too Many Requests, usually with a Retry-After header. The migration shows why standards win: generic HTTP clients, API gateways and retry libraries all understand 429 and back off properly, but know nothing about 420.
218 and 530: vendor inventions
| Code | Who uses it | What it is |
|---|---|---|
| 218 | Apache httpd has used it as a non-standard “This is fine” | Lets an application signal a problem while preventing server error-page overrides |
| 530 | Hosting and CDN providers, for example a platform’s frozen-site page; Cloudflare also uses 530 for its own errors | Provider-specific meaning, often “site frozen” or an origin problem |
These are not in the HTTP specification. Their meaning depends on who sent them, so a client cannot interpret them generally.
What the zoo teaches
A short selection guide for your own APIs
| Situation | Use |
|---|---|
| Too many requests | 429 with Retry-After |
| Not logged in | 401 |
| Logged in, not allowed | 403 |
| Does not exist (or you hide that it does) | 404 |
| Valid request, failed business validation | 422 (or 400) |
| Legally blocked | 451 |
| Dependency down, try again later | 503 with Retry-After |
Do
Stick to registered codes, return structured error bodies with a stable machine-readable error identifier, and include Retry-After on 429 and 503.
Don't
Invent a status code because none “feels right”. A new number is invisible to caches, proxies, monitors and client libraries, and it will be misread by anything that does not know your convention.
Takeaway
The weird codes are great trivia and a useful warning. HTTP’s power is that every layer between client and server agrees on what the classes and standard codes mean. Spend that shared understanding carefully: use the standard code, explain the specifics in the body, and leave the teapot for April.
Frequently asked questions
What does HTTP 451 mean?
Unavailable For Legal Reasons, defined in RFC 7725. The server is refusing a resource because of a legal demand, such as a court order or government block. The number is a nod to Fahrenheit 451. The response should explain the legal basis where possible, and a link to the demanding party where allowed.
Is HTTP 418 I'm a teapot a real status code?
It comes from RFC 2324, the Hyper Text Coffee Pot Control Protocol, an April Fools' joke. It is not part of the HTTP standard, yet it is widely recognised and some servers return it deliberately. It has been defended against removal from libraries by developers who like the joke.
Why was Twitter's 420 replaced?
420 Enhance Your Calm was a non-standard code some APIs used for rate limiting. The standard answer is 429 Too Many Requests, defined in RFC 6585, which clients, libraries and proxies understand. Replacing a bespoke code with the standard one lets generic retry logic work.
Should I invent my own HTTP status codes?
Almost never. Clients, proxies, caches and monitoring tools key off the standard classes: 2xx, 3xx, 4xx, 5xx. An unregistered code is treated by its class at best and confuses tooling at worst. Use the closest standard code and put the detail in a structured error body.
/* Comments */
Comments are offline right now — we reconnect automatically, nothing is lost.