HTTP Status Code Lookup

Look up any HTTP status code with its RFC reference, plain-language meaning, and guidance on when to send it. Covers all standard 1xx-5xx codes plus the common unofficial ones (418, 419, 451, 521-526, etc.).

How to use the HTTP Status Code Lookup

Type a number to look up by status code. Type a word (like "rate" or "unauthorized") to search names and descriptions. All codes load instantly; the search filters as you type.

How HTTP status codes are organized

HTTP status codes are 3-digit integers grouped by class:

  • 1xx (Informational) — request received, continuing. Rarely surfaced to applications.
  • 2xx (Success) — request was received, understood, and accepted. Default success is 200 OK; 201 for resource creation, 204 for success-with-no-body.
  • 3xx (Redirection) — further action needed. 301 permanent, 302/307 temporary, 304 not modified (cache hit).
  • 4xx (Client error) — the request was bad. 400 generic, 401 needs auth, 403 forbidden, 404 not found, 409 conflict, 422 unprocessable, 429 rate-limited.
  • 5xx (Server error) — server failed. 500 generic, 502 bad gateway, 503 unavailable, 504 timeout.

Choosing the right code matters because intermediaries (caches, CDNs, monitoring) treat them differently. A 503 with Retry-After tells clients to back off; a 500 implies a bug. A 422 says "your data is invalid"; a 400 says "your request is malformed."

Frequently asked questions

What's the difference between 401 and 403?
401 Unauthorized: the request lacks valid authentication. The client should authenticate and retry. 403 Forbidden: authentication succeeded but the authenticated principal is not allowed. Retrying with the same credentials will not help.

When should I return 422 vs 400?
400 Bad Request: the request itself is malformed (invalid JSON, missing required headers). 422 Unprocessable Entity: the request is well-formed but the data violates semantic rules (a required field is missing, a value is out of range). REST APIs typically use 422 for validation errors.

Is 418 I'm a teapot a real status code?
It was defined as an April Fools' joke in RFC 2324 (1998). Some servers and frameworks ship it; it has no production use. RFC 7168 reaffirmed it should not be removed (its removal had been proposed).

What about 200 with an error body?
Some legacy APIs return 200 OK even when the operation failed, with an error code in the body. This breaks HTTP semantics — caches, monitoring, retries all behave wrong. Modern REST APIs return appropriate 4xx/5xx codes.