418 I'm a Teapot
A joke status code from an April Fools' RFC, indicating the server refuses to brew coffee because it is a teapot.
Defined in RFC 2324 §2.3.2
What 418 means
The 418 status code originates from RFC 2324, "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", published on April 1, 1998 as a deliberate joke RFC. It defines 418 for the case where a coffee pot receives a request to brew coffee but is, in fact, a teapot and therefore cannot comply. It is not part of RFC 9110 and carries no real HTTP semantics of its own.
RFC 9110 acknowledges 418 explicitly but only to reserve it: the current core specification states the code is "Unused" and intentionally left undefined by that document, precisely so the joke code stays registered in the IANA HTTP Status Code Registry and cannot be reassigned to a new, unrelated meaning later. RFC 7168 later extended the joke with HTCPCP-TEA, adding tea-brewing semantics such as "please don't shake" for delicate blends.
Despite its origins, 418 is widely implemented as an easter egg: Google's API infrastructure, GitHub's API in past versions, and numerous web frameworks (Express middleware, Flask extensions) ship a literal teapot endpoint. Developers should treat it as a novelty, never as a substitute for a real 4xx code like 400 or 406 in production error handling, since most tooling and monitoring systems do not expect to see it outside of jokes.
Common causes
- A developer implements 418 deliberately as an easter egg or joke endpoint.
- An HTCPCP-compliant "teapot" server receives a BREW or POST request asking it to brew coffee, per RFC 2324.
- A framework or library ships a built-in "/teapot" route used for demos or to test error-handling paths.
- A coding challenge, interview exercise, or CTF uses 418 to see how a client handles a nonstandard status code.
- An API gateway has a whimsical fallback rule that maps certain unmatched requests to 418 instead of 404.
How to fix a 418
If you are the client (browser user or API caller)
- Treat 418 as an ordinary 4xx client error for control-flow purposes rather than special-casing it.
- Do not build production logic around 418 semantics, since it is outside RFC 9110 and not guaranteed to be present.
- Log and alert on an unexpected 418 response, since in a real API it almost always signals a debug or easter-egg route rather than an intended production error.
If you run the server
- Reserve 418 strictly for intentional easter eggs or genuine HTCPCP compatibility, not for real application errors.
- Document any deliberate 418 usage clearly, since automated clients and monitoring tools generally do not expect it.
- Use standard codes like 400 or 406 for real validation or content-negotiation failures instead of borrowing 418 for serious errors.
Example
POST /coffee HTTP/1.1
Host: pot.example.com
Content-Type: message/coffeepot
BREW
HTTP/1.1 418 I'm a Teapot
Content-Type: text/plain
I cannot brew coffee because I am, permanently, a teapot.Try it live
Our free status responder returns a real HTTP 418 you can point tests, monitors or a browser at.
GET https://mcp.httpstatus.com/status/418