HTTP Status Code Reference

Looking up whether 422 is the right status for a validation error or whether you should use 400 is a recurring decision when designing an API.

This reference covers all standard HTTP status codes (1xx through 5xx) plus the common non-standard ones you'll see in the wild — 418 (I'm a teapot), 451 (legal restriction), 599 (network connect timeout, used by some proxies). Each entry includes the standard description, when to use it, and notes on common misuses.

Filter by class (informational, success, redirect, client error, server error) or search by code or keyword. The 4xx versus 5xx distinction matters because monitoring systems often page on 5xx but ignore 4xx — picking the right code affects whether your on-call gets woken up.

The status code classes are designed so the first digit alone tells you the broad category: 1xx informational, 2xx success, 3xx redirect, 4xx client error, 5xx server error. The specifics within each class encode the precise reason. This matters operationally because monitoring tools, CDNs, and load balancers all act on the class. PagerDuty alerts on 5xx because something on your infrastructure is broken. Cloudflare retries on 502/504 because the origin might be transiently down. Browsers cache 301 indefinitely but not 302. Picking the right code triggers the right downstream behavior.

The friction this captures: you're designing an API endpoint and the client sends invalid data. Should you return 400 or 422? Both are 'client error.' The standard distinguishes: 400 means the request itself is malformed (broken JSON, missing required headers), 422 means the request was syntactically valid but the content failed validation rules. Most APIs use 400 for everything because it's simpler, but if you care about clients distinguishing 'I sent garbage' from 'my email field had the wrong format,' 422 is the more precise code.

Worked example: a user submits a signup form with a duplicate email. What status do you return? 409 (Conflict) is technically the most precise — it indicates a state collision. Many APIs return 422 instead because the framework's validation library defaults to that. Some return 400 because they conflate validation with parse errors. None of these are catastrophically wrong, but 409 is the answer that matches the spec's intent. The reference flags this in the entry for 409.

Where this gets contentious: 401 vs 403. The HTTP RFC says 401 means 'authentication required or failed,' 403 means 'authenticated but not authorized.' The intuitive read is reversed for many developers — 'you're forbidden' sounds stronger than 'you're not authorized.' The spec is clear; common implementations vary. APIs that return 403 when no auth header is present are technically wrong but pragmatically common. Don't lose sleep over it; do document what your API does so client developers know.