HTTP 431 request header fields too large

What 431 means

HTTP 431 Request Header Fields Too Large, defined in RFC 6585, says the server is unwilling to process the request because its header fields are too large. It can mean the total of all request headers is over the limit, or that a single header is too large. When one field is the culprit, the spec recommends the response name that field. Unlike 413, which is about the request body, 431 is about the metadata sent before the body, so a large file upload is a 413 problem, not this one. Note also the distinction from a plain 400: 431 means the request syntax is fine but the headers are simply too big. Some servers, notably nginx, predate RFC 6585 and report the same condition as a 400, which is why you may see "Request Header Or Cookie Too Large" rather than 431.

Responses with 431 must not be stored by a cache, and, because it is a request-level rejection, it is separate from the body-size problem covered in the 413 payload too large article.

The dominant cause: cookies

In practice the single most common cause is an accumulated cookie jar. A browser sends every cookie it holds for a domain on each request in the Cookie header, and that header is part of the request headers. Over time a domain can accumulate many cookies, some large; analytics, advertising, consent and marketing tags each add their own. When the combined Cookie header pushes the request past the server's header limit, the site fails to load with a 431 even though nothing about the server changed.

An auth token in a header is a second common cause. A single very large bearer token or a custom header that has grown over time can cross the per-field ceiling on its own.

Server-side defaults

Reduce size or raise the limit

For a genuine user-facing 431, the right target is the cookie size, not the server. Have the affected user clear the site's cookies and retry; that immediately resets the header to a single entry and resolves the error. On the server side, the lasting fix is to stop storing so much in cookies: move large or long-lived profile and preference data into server-side or local storage and keep only a small session identifier in the cookie. See the 400 bad request article for the boundary between a malformed request and a size rejection.

If the 431 is coming from an API client sending a large token, either reduce the token or split the metadata: prefer sending a compact reference that the server resolves, rather than inflating every request. Only raise large_client_header_buffers or LimitRequestFieldSize as a deliberate change once you have confirmed legitimate headers, not runaway cookies, are the cause. Because a 431 stops the page before it loads, pair the fix with the user-facing error pages practices so a residual failure is at least clear to the visitor.