431 Request Header Fields Too Large

The short version: Clear the cookies for that one website. Cookie bloat is the cause in the overwhelming majority of cases, and clearing them for a single domain fixes it without touching the rest of your browsing. If you run the website, raise large_client_header_buffers on nginx to stop people being locked out, then reduce what you are storing in cookies, because headers travel with every request.

Key takeaways

• 431 Request Header Fields Too Large means the request headers were too big for the server to process, either one oversized field or all of them combined.
• Cookies are the usual culprit, because every cookie for a domain is sent on every request, and they accumulate across applications sharing that domain.
• nginx answers the same condition with 400 Bad Request: Request Header Or Cookie Too Large instead of 431, so the identical problem appears under two status codes.
• For a visitor, clearing that one website's cookies fixes it almost every time, and requires nothing from the website owner.
• Raising the server buffer stops people being locked out, but headers ride on every request, so bloated ones are a permanent cost rather than a one-off error.

Error type

HTTP 4xx client error

Whose side

Usually the request; sometimes a buffer set too low

Fix difficulty

Easy

Common cause

The request headers exceeded the server buffer

What does 431 Request Header Fields Too Large mean?

A 431 Request Header Fields Too Large means the server refused to process the request because its headers were too big. RFC 6585 defines it for two related situations: a single header field that is oversized on its own, and a set of fields whose combined size passes what the server will accept. The specification suggests the response should indicate which field was at fault, though few servers actually do, which is part of why the error is more confusing in practice than it needs to be. What matters is that nothing is wrong with the URL or the page, only with everything the browser attached to the request.

Cookies dominate the causes, because of how they work. Every cookie set for a domain is sent on every request to that domain, so they accumulate rather than replace one another. Add an SSO layer storing claims, several applications sharing the same domain, and a chain of proxies each appending forwarded headers, and an ordinary page request can carry several kilobytes of headers without anyone intending it. nginx, meanwhile, reports the same condition as 400 Bad Request: Request Header Or Cookie Too Large, so the identical problem is documented under two different status codes depending on which server answered.

431

HTTP status code, defined in RFC 6585 alongside 428, 429 and 511

8 KB

The default header buffer on nginx, and the limit most requests run into first

4 KB

The maximum size of a single cookie in most browsers, so a handful is enough to exhaust the buffer

How the 431 Request Header Fields Too Large error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

431

Request Header Fields Too Large

The request headers were too large for the server to process.

• 431 Request Header Fields Too Large
• HTTP Error 431
• Error 431
• 400 Bad Request: Request Header Or Cookie Too Large
• Request Header Or Cookie Too Large
• Header too long

431 vs 413, 414 and 400

Four codes that all appear when something about a request is too big, distinguished by which part of it.

Which part of the request was too large

Three status codes cover three different parts of a request, and each has its own server setting.

What causes 431 Request Header Fields Too Large?

• Cookie accumulation for a domain, where every cookie is sent on every request and several applications on the same domain each add their own.
• A large authentication token in a cookie or an Authorization header, such as a JWT carrying many claims.
• An SSO or identity layer storing session state, group memberships, and roles in cookies rather than server-side.
• A chain of proxies or load balancers each appending forwarded headers, which stack up and push an otherwise normal request past the limit.
• A server buffer set lower than the default, or left at the default on an application whose headers legitimately need more room.
• A redirect loop through an authentication flow that accumulates state parameters and cookies with each hop.
• Development or debugging headers left enabled in production, adding size to every request without anyone noticing.

How to find the cause fast

1. Reproduce with curl -v and read the request headers it prints. An oversized Cookie line is usually obvious immediately.
2. Open the page in an incognito window. Working there points squarely at cookies, since incognito starts without them.
3. Inspect the cookies for the domain in browser devtools and note their sizes and which paths they apply to.
4. Check whether the error appears only after signing in or after a redirect chain, which points at the auth layer as the source of the bloat.

Terminal

curl -sI https://example.com -H "Cookie: $(head -c 9000 /dev/zero | tr '\0' 'a')"HTTP/1.1 431 Request Header Fields Too Large# 9 KB of cookie against an 8 KB default buffer

How 431 Request Header Fields Too Large looks from the outside

A 431 is a normal HTTP response, so from outside the server looks perfectly healthy and an up-or-down check will report it up. What makes this error particularly awkward is that it is stateful: it affects visitors who have accumulated enough cookies, and not the monitor, which arrives with none. A synthetic check will sail through while signed-in users are locked out entirely, and the people affected are your most engaged ones, since cookies accumulate with use. Checking a signed-in path, rather than only the public homepage, is what makes this class of failure visible.

To confirm the exact code a URL returns, or to re-test several at once after a fix, run them through the free bulk URL status checker.

How to fix 431 Request Header Fields Too Large

If you are a visitor

1. Clear the cookies and site data for that specific website. This fixes the overwhelming majority of cases and does not disturb your other browsing.
2. Try an incognito or private window, which starts with no cookies and confirms the diagnosis in seconds.
3. Sign out and back in after clearing, so the website issues a fresh, smaller set of cookies.
4. Disable browser extensions temporarily, particularly any that add headers or manage sessions.
5. If it fails in incognito too, the request is not carrying your cookies and the problem is on the website's side, so report it to the owner.

If you run the website

1. Raise large_client_header_buffers and client_header_buffer_size on nginx, then reload. This stops visitors being locked out while you address the cause.
2. Audit what you are storing in cookies. Keep an identifier and hold the state server-side, which is the only fix that survives the application growing.
3. Scope cookies to the paths and subdomains that need them, so one application does not lock visitors out of every other service on the domain.
4. Check your proxy chain for accumulated forwarded headers, and strip the ones nothing downstream reads.
5. Set sensible expiry on cookies so stale ones are discarded rather than accumulating indefinitely.
6. Return a helpful message rather than a bare status. A 431 that tells the visitor to clear their cookies resolves itself; one that does not becomes a support ticket.

Still not fixed? Next steps

• Measure the actual header size with curl -v rather than guessing. A Cookie line running to several kilobytes is usually visible at a glance.
• Identify which cookies are large and which application set them. On a shared domain, one service can lock visitors out of all the others.
• Raise large_client_header_buffers and client_header_buffer_size on nginx as an immediate measure, then reduce what is being stored.
• Check whether a proxy, SSO layer, or gateway is adding headers of its own, since forwarded headers stack up through a chain and can push a normal request over the limit.
• Move session state server-side and keep only an identifier in the cookie. This is the only fix that stops the problem returning as the application grows.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Raise the nginx header buffers

# in the http block, then reload nginx
http {
  client_header_buffer_size   4k;
  large_client_header_buffers 4 16k;
}
# the default is 8k; this is relief, not a cure

See how big the request headers actually are

curl -v https://example.com 2>&1 | awk '/^> /{n += length($0)} END{print n " bytes of request headers"}'
# then look at the Cookie line specifically
curl -v https://example.com 2>&1 | grep -i '^> cookie' | wc -c

Keep an identifier in the cookie, not the state

// bloats every request, forever
setcookie("profile", json_encode($fullUserObject));

// one small identifier; the data lives server-side
setcookie("sid", $sessionId, ["httponly" => true, "samesite" => "Lax"]);

How to prevent 431 Request Header Fields Too Large

A 431 is stateful in a way that defeats ordinary checks: it strikes visitors who have accumulated enough cookies, and never the monitor, which arrives with none. So a synthetic check passes happily while your most engaged signed-in users are locked out completely, and the first sign is a support ticket. Pulsetic checks your website and endpoints from multiple locations every 30 seconds and alerts you by email, SMS, voice call, Slack, Discord, Telegram, or webhook when a URL stops returning the status code you expect, so a path that starts refusing real sessions does not stay invisible.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.

Sources and further reading

The specifications and vendor documentation this guide is written from, plus deeper reading on the parts it only summarises.

• MDN: 431 Request Header Fields Too Large
• RFC 6585: Additional HTTP Status Codes
• MDN: Using HTTP cookies
• RFC 6585: Additional HTTP Status Codes