HTTP Status Codes
HTTP 418 I'm a teapot
I'm a teapot — server refuses to brew coffee because it is permanently a teapot
Status 418 is the famous I'm a teapot response: the server deliberately refuses the request as an HTCPCP joke, not because anything failed. It started as RFC 2324, an April Fools' prank from 1998, and became a novelty code that real frameworks implement. Sites and APIs return it on purpose — an easter egg, a test sentinel, or a playful block.
Visual summary
A quick reference view of how HTTP 418 works: A sleek, diagrammatic teapot rejecting a coffee-related request.
What 418 Means
The shortest useful reading of this status code.
I'm a teapot means server refuses to brew coffee because it is permanently a teapot.
This status falls into the 4xx class, indicating a client-side error outcome for the request.
Quick read
I'm a teapot
server refuses to brew coffee because it is permanently a teapot
Technical Context
How this status behaves without turning the page into a repair guide.
Standard usage
Originally specified in RFC 2324 as part of the Hyper Text Coffee Pot Control Protocol (HTCPCP), the 418 code was specified for teapots requested to brew coffee. Despite its origins as satire, it was implemented across numerous software libraries, including Node.js, Go, Python, and ASP.NET.
Technical nuance
RFC 9110 keeps 418 out of the defined codes: the specification records that so many implementations shipped it as a joke that the number became unusable for any future purpose, and holds it reserved in the IANA registry so it cannot currently be assigned to another application.
Related HTTP Codes
Nearby HTTP status codes help clarify how 418 differs inside the same response family.
418
I'm a teapot
server refuses to brew coffee because it is permanently a teapot
400
Bad Request
the server cannot process the request because it is malformed
404
Not Found
the server cannot find the requested resource at this URL
500
Internal Server Error
the server hit an unexpected condition while handling the request
Common Causes
RFC 2324 Hyper Text Coffee Pot Control Protocol demonstration
A common condition that triggers a 418 response when the web server evaluates the transaction.
API endpoint returning deliberate easter egg response for unexpected beverage commands
A common condition that triggers a 418 response when the web server evaluates the transaction.
Web application framework using 418 as an intentional sentinel or mock test response
A common condition that triggers a 418 response when the web server evaluates the transaction.
Test suites simulating rare status codes to verify client-side error handling
A common condition that triggers a 418 response when the web server evaluates the transaction.
Typical Scenarios
A developer queries a mock test endpoint configured to return 418 during system verification
An API returns 418 as an easter egg when receiving nonsensical or humorous request parameters
A web application uses 418 to signal that an endpoint is intentionally non-operational
A bot-mitigation layer answers known automated clients with 418 as a deliberate, unmistakable block
What To Know
Encountering a 418 status indicates an intentional easter egg, mock test endpoint, or humorous sentinel response. It is not an infrastructure malfunction.
Frequently Asked Questions
Common interpretation questions about HTTP 418.
It began as a joke in RFC 2324 and is now reserved in IANA's registry of HTTP status codes. The reservation means the number cannot be assigned to any other purpose today, though a future re-assignment remains possible if the 4xx range ever runs out.
Many web services and frameworks include 418 as an easter egg, sentinel value for testing, or to indicate deliberately unsupported operations.
From RFC 2324, a satirical document published on 1 April 1998 describing a protocol for controlling coffee pots. Its teapot rule says a teapot asked to brew coffee answers with 418, and the joke extends to the response body: it may be short and stout.
Only by convention. Because the code is reserved, every use is application-defined: a site can flag bot traffic, mark an endpoint as deliberately non-operational, or serve a test sentinel. The response body or API documentation, not the standard, explains why it appeared.