HTTP 4xx Client Error Codes

An HTTP 4xx response means the server cannot or will not process the request because of something associated with the request. That does not always mean the human visitor made a mistake: a CDN, firewall, expired credential, malformed link, or client library can also be responsible.

Common 4xx codes

400 Bad Request

Use 400 for malformed syntax, invalid message framing, or a request that cannot be parsed. For an API, return a stable error code and identify invalid fields without exposing secrets or internal stack traces.

401 Unauthorized

Despite its name, 401 means the request lacks valid authentication credentials. Include a WWW-Authenticate challenge. Use 403 when credentials are accepted but the caller is not permitted to perform the action.

403 Forbidden

Use 403 when the server understands the request but refuses it. A CDN or WAF can generate 403 for a blocked IP address, failed bot rule, invalid signed URL, geography rule, or origin access policy. Record which layer generated the response.

404 Not Found

Use 404 when no current representation exists. It is also reasonable to use 404 instead of 403 when revealing that a protected resource exists would leak information.

For removed site content, redirect only when a close replacement exists. Otherwise return 404 or 410 and remove the URL from internal links and sitemaps.

405 Method Not Allowed

Use 405 when the method is recognised but is not supported by the target resource. Include an Allow header:

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

Use 501 when the server does not implement the method at all.

406 Not Acceptable

Use 406 when proactive content negotiation cannot produce a response that matches headers such as Accept or Accept-Language. In many applications it is more useful to serve a default representation, so use this code deliberately.

408 Request Timeout

Use 408 when the server is no longer willing to wait for the client to finish the request. Distinguish it from 504, where a gateway waited too long for an upstream server.

409 Conflict

Use 409 for a conflict with current state, such as a duplicate unique value or an invalid state transition. Explain how the client can resolve the conflict.

410 Gone

Use 410 when a resource was intentionally removed and no replacement exists. It is more explicit than 404, but both are valid for removed content. Consistency and correct internal links matter more than changing every permanent removal to 410.

412 Precondition Failed

Use 412 when a condition such as If-Match or If-Unmodified-Since fails. Conditional updates prevent one client from silently overwriting another client’s change.

413 Content Too Large

Use 413 when the body exceeds a configured limit. If the condition is temporary, a server may include Retry-After. Check limits at the browser upload path, CDN, load balancer, application server, and application itself.

414 URI Too Long

Use 414 when the request target is longer than the server will process. Common causes are an accidental redirect loop that appends parameters, large data placed in a query string, or an attack.

415 Unsupported Media Type

Use 415 when Content-Type or Content-Encoding is not supported. Do not silently guess the body format when doing so could produce a different meaning.

416 Range Not Satisfiable

Use 416 when no requested byte range overlaps the selected representation. This commonly appears in download and video delivery. Return the current length in Content-Range when it is known.

422 Unprocessable Content

Use 422 when the request format is understood but its instructions cannot be processed. It is suitable for semantic validation errors. Use 400 when the request itself cannot be parsed.

425 Too Early

Use 425 when processing a request carried in TLS early data would risk replay. The client can retry after the handshake completes.

428 Precondition Required

Use 428 when the origin requires a conditional request, commonly If-Match, to prevent lost updates.

429 Too Many Requests

Use 429 when a client exceeds a rate limit. Include Retry-After when possible and document whether the limit applies by credential, IP address, route, or account.

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Do not make every client retry at the same moment. Clients should use bounded exponential backoff with jitter.

431 Request Header Fields Too Large

Oversized cookies are a common cause of 431. Check the aggregate header size as well as individual fields, and remember that a CDN and origin can have different limits.

451 Unavailable For Legal Reasons

Use 451 when access is denied because of a legal demand. Provide an explanation and the responsible party when policy and law allow it.

4xx caching and CDN diagnosis

Several status codes, including 404, 405, 410, and 414, are defined as heuristically cacheable. A CDN may also apply explicit negative-caching rules. This can protect an origin from repeated misses, but it can preserve an error after the origin is fixed.

When investigating a 4xx response:

1. Capture the status, response headers, body, request ID, and time.
2. Check whether the response was generated by the CDN, WAF, load balancer, or origin.
3. Compare a request through the CDN with an authorised direct-origin request.
4. Inspect cache status and age headers.
5. Purge only after fixing the cause; a purge does not repair an origin or policy error.

Sources and related reading

• RFC 9110: 4xx client errors
• HTTP caching
• Purging CDN content
• HTTP 5xx server errors
• Choosing an HTTP status code