HTTP 418 I'm a Teapot
HTTP 418 I'm a Teapot has a delightfully absurd origin: it was written as an April Fools' Day joke RFC in 1998 (RFC 2324) defining the Hyper Text Coffee Pot Control Protocol (HTCPCP). The protocol defines how to control networked coffee pots over HTTP, and 418 is the response when a teapot receives a BREW command — it is a teapot, it cannot brew coffee.
The code has no practical use, but it became a beloved internet in-joke and is supported by major infrastructure providers as an Easter egg. When Mark Nottingham proposed removing it from the IANA registry in 2017, the developer community responded with a 'Save 418' petition that was ultimately successful. The code stays — as a monument to the fact that protocols can have a sense of humor.
If you encounter 418 in a production log, a developer almost certainly added it intentionally. If you are building an API and want a friendly rejection for invalid-but-humorous requests, 418 is the conventional choice.
Quick reference
| Code | 418 |
|---|---|
| Name | I'm a Teapot |
| Category | 4xx client errors |
| Specification | RFC 2324 |
| IANA status | Unused / Reserved |
| When to use | Use it as an Easter egg, a custom error for novelty endpoints, or a developer joke. Do not use in production APIs that need to communicate real error semantics. 418 has no defined client behavior beyond amusement. |
| Client behavior | Smile. Optional. |
| Caching | Cache the teapot. It will not become a coffee machine. |
Common causes
- Someone is attempting to brew coffee using a teapot protocol
- A developer deliberately returned 418 as a custom error or Easter egg
- The HTCPCP/1.0 protocol (RFC 2324) is being honoured
How to fix it
- If you see this in production, a developer almost certainly added it intentionally
- For real errors, use an appropriate 4xx code (400, 422, etc.)
Example exchange
BREW /coffee HTTP/1.1 Host: api.example.com Content-Type: message/coffeepot HTTP/1.1 418 I'm a Teapot Content-Type: text/plain I'm a teapot, not a coffee machine.
When you see this in production
418 in production is almost always intentional. It appears in: novelty endpoints, Easter egg responses to specific request patterns, and sometimes as a custom response for detected abuse patterns (some Cloudflare configurations). It has no operational significance beyond the developer joke.
What developers usually do next
- If you see 418 unexpectedly: search your codebase for where it is being returned. If you added it intentionally and your monitoring is alerting on it, add an exception for 418 in your error monitoring rules.
When NOT to use this code
Do not use 418 for real validation errors (use 400, 422, or 403). Do not use 418 in APIs where the consumer does not share your sense of humor. Do not document 418 as a real error code in your API specification unless it is genuinely an Easter egg you want consumers to find.
Related status codes
Frequently asked questions
Is HTTP 418 a real status code?
It was defined in RFC 2324 as an April Fools' Day joke in 1998, so it is technically specified but not a serious protocol feature. The IANA HTTP Status Code Registry lists it as unused, but it is deliberately kept alive as a cultural artifact.
Why wasn't 418 removed from the registry?
In 2017, Mark Nottingham proposed removing 418. The internet community responded with significant pushback, including petitions and the 'Save 418' movement. It was preserved as a deliberate Easter egg with acknowledged unused status.
Which servers actually return 418?
Google's teapot Easter egg (google.com/teapot), some Cloudflare responses, and various developer-added Easter eggs across the web return 418.
Standards reference
This definition is derived from the IANA HTTP Status Code Registry and RFC 2324. Human-readable operational guidance by ErrorLookup. · HTTP 418 quick reference →