What HTTP 431 means

HTTP status code 431 stands for “Request Header Fields Too Large.” It’s a server response indicating that the incoming request contains one or more header fields whose combined size exceeds what the server is willing to accept.

A key point is that this is about request headers, not the message body and not the URL alone. If the server rejects the request with 431, it’s essentially saying: “I’m not going to process this request because the metadata in the headers is too big.”

How 431 works (the mechanics)

When a client (browser, app, API consumer, gateway) sends an HTTP request, it includes:

  • the request line (method, path, query),
  • headers (e.g., Host, Authorization, Cookie, Accept-*, custom headers),
  • optionally a request body.

Servers and intermediaries apply size limits to headers. If the headers (often measured as total header bytes, sometimes with per-header limits) exceed those thresholds, the server returns 431 and stops handling the request.

Because the exact thresholds differ by server software and configuration, 431 is frequently encountered when an application grows header content over time—examples include long session cookies, verbose authorization tokens, or added custom headers from SDKs and proxies.

Common causes and where the size grows

431 usually appears due to one of these patterns:

  • Large cookies: Many applications store session state, preferences, or flags in cookies. If cookies grow (or multiple cookies accumulate), the header footprint rises.
  • Long authorization tokens: Some auth methods use large bearer tokens or include multiple claims that can substantially increase the Authorization header.
  • Custom headers added by clients: Debug headers, tracing metadata, tenant identifiers, or repeated key/value pairs can add up.
  • Redirection or proxy chains: In some architectures, intermediaries may add headers (or consolidate them) which increases total header size before it reaches the final server.
  • Unexpected duplication: Misconfigured clients or gateways can duplicate header fields, multiplying the byte count.

Differences and limits (what 431 is not)

  • Not 413: 413 “Payload Too Large” is typically about the request body size, not headers.
  • Not 414: 414 “URI Too Long” is about an excessively long URL (or request target), not header fields.
  • Not 400 (in general): 400 “Bad Request” covers many malformed request cases. 431 specifically points to header size.

Important limitation: Even if you see 431, you can’t assume the server has a single fixed limit you can safely “guess.” Different components in the path (CDN, reverse proxy, application server) may have their own limits. So the same request might work in one environment but fail in another.

Practical checks you can run

Use these checks to pinpoint what’s too large and to confirm the problem is header size:

  • Confirm the status code and response timing: If you consistently get 431 for certain requests (and not others), that’s a strong indicator of systematic header size overflow.
  • Measure header size from the client side: In many developer tools and HTTP logging systems, you can inspect the raw headers and estimate total bytes.
  • Find the largest header fields: Look specifically at Cookie, Authorization, and any custom headers your application sends.
  • Reproduce with minimal headers: Temporarily reduce non-essential custom headers and resend. If 431 disappears, you’ve narrowed the cause to the removed header content.
  • Compare “works vs fails” requests: If the same endpoint sometimes succeeds, diff the header sets between successful and failing requests.

If you control the server, you can also verify the configured header limits (or proxy limits) and map which component is generating the 431. If you don’t control the server, rely on diagnostics and request comparisons, since you may not know which hop is enforcing the limit.

A few concepts often get mixed with 431:

  • Header size limits: These are server/proxy safeguards to prevent excessive resource usage.
  • Token/session design: Auth and session approaches that store substantial data in headers can push systems into size-limit territory.
  • Observability: Good request logging (including header lengths, if available) makes header-related failures much easier to diagnose.

Because thresholds vary by environment and configuration, treat 431 as a symptom. The actionable outcome is to reduce the byte footprint of request headers or adjust the relevant header limits where you control that infrastructure.

Uncertainty note: Without knowing your specific server or proxy software and configuration, the exact rule (total bytes vs per-header limit, and the precise threshold) can’t be determined from the status code alone.