HTTP 418 I'm a teapot – Free, Online, Private

What HTTP 418 means

418 was defined as an April Fool's status for a teapot asked to brew coffee. It is registered, and RFC 9110 still notes it. It is not a signal with interoperable client behavior. People return it for Easter eggs. A client that sees 418 in production has found a joke or a test, not a state it can recover from. Do not build a contract on it.

418 I'm a teapot belongs to the 4xx client error class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 418

When you see HTTP 418 I'm a teapot, stop on that exact status line. 418 I'm a teapot is the HTCPCP joke status. It is not an API error code. The trace that usually produces it: A demo server returned 418 and a monitoring tool paged someone. The 4xx client error class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Do not return 418 from an API you expect strangers to operate. If you return it anyway, know that generic clients will treat it as an unrecognized 4xx and stop. Use a real 4xx for a real refusal. The status exists so the joke has a number, not so payment or auth flows have a secret code.

How to fix HTTP 418

To fix HTTP 418, change the condition that made the server choose I'm a teapot. Treat 418 as a final 4xx you do not retry. Do not special-case it unless you are talking to a server that documented the joke. There is no recovery procedure. Do not retry. The teapot will not become a coffee pot. If the log line is a different code, leave this page. The mix-up people make with 418 is this one: It is not 400, 403, or 501. Those mean something a client can act on. 418 means the server is performing the teapot joke.

• A client library's default case logged 418 as an unknown status and crashed a strict parser.
• A test fixture leaked into production.
• Someone mapped 418 to a business rule and no other implementation agreed.

An access log that only stores 418 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 418 I'm a teapotHTTP/1.1 418 I'm a teapot
Content-Type: text/plain

I'm a teapot

The body is the joke. There is no challenge header and no retry hint. A monitoring system that alerts on every 4xx will alert on this. That is a reason to keep it out of production metrics, or to filter it if you insist on the Easter egg.

What the client should do

Treat 418 as a final 4xx you do not retry. Do not special-case it unless you are talking to a server that documented the joke. There is no recovery procedure.

Do not cache 418 as a representation anyone depends on.

Do not retry. The teapot will not become a coffee pot.

Codes people confuse with HTTP 418

It is not 400, 403, or 501. Those mean something a client can act on. 418 means the server is performing the teapot joke.