The server has received the request headers, and the client should go ahead and send the body.
When to use it
Sent in reply to Expect: 100-continue, so a client can check that a large upload will be accepted before sending it. Servers and frameworks handle this for you.
The request succeeded. The body depends on the method: the resource for GET, the result of the action for POST.
When to use it
The default success response for GET, and for POST, PUT or PATCH when you return a body.
Common mistake
Sending 200 with an error in the body, such as {"error": "not found"}. Caches, monitoring, retries and client libraries all trust the status code, so failures need a 4xx or 5xx.
The resource has a new permanent URL, given in the Location header.
When to use it
Permanent URL changes such as domain moves, HTTP to HTTPS and renamed pages. Search engines pass ranking to the new URL.
Common mistake
Browsers may turn a POST into a GET when following a 301; use 308 if the method must be kept. Browsers also cache 301s hard, so test a new rule with 302 first.
The resource is temporarily at another URL, given in the Location header.
When to use it
Temporary redirects of GET requests, such as sending a signed-out visitor to the login page.
Common mistake
Using 302 after a form POST. Browsers switch to GET in practice, but the spec doesn’t promise it. Use 303 to say “now GET this page”, or 307 to repeat the same method.
The server has nothing at this URL. It doesn’t say whether that is temporary or permanent.
When to use it
Unknown routes and IDs that don’t exist. Also acceptable for hiding resources the requester mustn’t know about.
Common mistake
Sending 200 with a “page not found” message, a soft 404 that search engines index and monitoring misses. If the resource was removed for good, 410 is clearer.
The request conflicts with the current state of the resource.
When to use it
Edit conflicts, duplicate unique values such as a taken username, and disallowed state changes like cancelling a shipped order. Explain how to resolve it.
Common mistake
Using 409 for ordinary validation errors (400 or 422). For optimistic locking with If-Match, 412 is the precise code.
An April Fools’ joke from the 1998 Hyper Text Coffee Pot Control Protocol: a teapot refusing to brew coffee. RFC 9110 reserves 418 as “(Unused)” because so many servers implement the joke.
When to use it
Easter eggs only. Some sites send it to turn away bots without explanation, which confuses everyone.
Common mistake
Using it as a real error in an API. It is a joke, and clients can’t act on it; pick a meaningful code.
The request reached a server that can’t produce a response for this combination of scheme and host.
When to use it
HTTP/2 connection reuse: a connection opened for one hostname gets reused for another the server doesn’t handle. The client retries on a new connection.
The server hit an unexpected condition. It is the generic catch-all for server-side failures.
When to use it
Unhandled exceptions and bugs. Log the details on the server, and give the client a reference ID rather than a stack trace.
Common mistake
Using 500 for client mistakes like validation errors or missing records; those are 4xx and shouldn’t page anyone. Never leak stack traces or SQL in the body.
The client has to authenticate to get network access, usually through a captive portal.
When to use it
Captive portals on hotel, airport and café Wi-Fi send it while intercepting traffic until you sign in or accept the terms. Origin servers shouldn’t send it.