HTTP 4xx Client Error Status Codes

Typically caused by malformed syntax, invalid framing, or deceptive routing.

Usually returned when credentials are missing, expired, or invalid. `WWW-Authenticate` is commonly involved.

Historically reserved; sometimes reused by APIs for billing or quota semantics.

The server understood the request but refuses access.

Common when a route or object is missing.

Typically accompanied by an `Allow` header listing permitted methods.

Occurs when content negotiation cannot satisfy the `Accept` headers.

Like `401` but for authenticating with a proxy.

Often indicates the client was too slow sending the request.

Common with version conflicts, duplicate creates, or edit collisions.

Like 404, but with stronger intent that the resource is gone permanently.

The server refuses the request without a defined content length.

Often used with `If-Match`, `If-Unmodified-Since`, or similar headers.

Returned when the request body exceeds server limits.

Often caused by oversized query strings or redirect loops.

Typical when sending JSON without `Content-Type: application/json` or sending the wrong media type.

Used when a range is outside the current representation length.

Often associated with unsupported `Expect` semantics.

Known from RFC 2324; commonly referenced humorously in developer contexts.

Defined for HTTP/2 scenarios where the connection was reused for the wrong authority.

Common for validation errors in APIs where JSON is syntactically valid but semantically invalid.

Often associated with WebDAV-style locking semantics.

One requested action failed because another failed.

Used to avoid processing a request that could be replayed too early.

The server requires a protocol upgrade before continuing.

Common to force safe updates and avoid lost updates. RFC 6585 defines it.

The canonical response for rate limiting. RFC 6585 defines it.

Often caused by oversized cookies or custom headers.

Defined for resources blocked because of legal demands.