431 Error | Fix Header Bloat Before It Breaks

You click a page and it just won’t load. Maybe it works in an incognito tab. Maybe it works on mobile data but not on Wi-Fi. When that pattern shows up, a 431 error is often the culprit.

Fixes take minutes once you spot it.

It’s an HTTP status code that points at one thing: the headers your browser sent were bigger than the server will accept. Headers include cookies, authentication tokens, and a handful of “metadata” fields that ride along with every request. When they grow past a limit, the server shuts the door.

This guide walks you through the fast checks that solve most cases, then the deeper fixes that keep the issue from coming back. If you’re a site owner, you’ll also see the server-side knobs that raise header limits, plus the tradeoffs that come with bigger buffers.

What The Status Code Means In Plain Terms

A browser request has two parts: what you’re asking for, and the extra context you send along. That extra context is the request headers. Cookies live there. So do sign-in tokens and some security headers.

When a server returns a 431 error, it’s saying it won’t process the request because the header fields were too large. The fix is not “refresh harder.” The fix is to reduce header size, or raise the server’s header limits when that’s safe and justified.

You’ll see this error most often after one of these changes:

• Cookie growth — A site stores too many cookies, or stores too much data inside one cookie.
• Login token growth — A session token, JWT, or SSO assertion balloons because of extra claims or attributes.
• Header fan-out — A proxy chain adds headers at each hop until the total crosses a limit.
• Long referrer or request line — A very long URL path or referrer can push some stacks over the edge.

If you want the formal definition, the status is “431 Request Header Fields Too Large.” It comes from RFC 6585, and it covers both cases: one oversized header field, or a header set that’s too big in total.

431 Error Triggers You Can Spot Fast

Quick check: start by proving it’s header size, not the page itself. The goal is to change what headers the browser sends and see if the error disappears.

Cookies That Snowball Over Time

Cookies are the most common trigger. A single site can set multiple cookies across subdomains, then your browser sends them all back on every request to that domain. Over months, this can turn into a big header block.

Sites also create oversized cookies by stuffing JSON blobs, A/B test payloads, or user preferences into a cookie instead of storing them server-side. It works, until it doesn’t.

Authentication Headers That Get Too Heavy

If your app uses an Authorization header with a large bearer token, it can hit size limits fast. This shows up with SSO, large JWT claim sets, or apps that keep adding claims “just in case.”

Some teams also pass identity data in custom headers between services. That can work in small deployments, then fail after more services join the chain.

Proxy And CDN Layers Adding Headers

Reverse proxies, CDNs, WAFs, and API gateways can add headers for tracing, geo, bot detection, and security. Each layer can add a little more. A request that looks fine to your app might already be near the header limit by the time it arrives.

This is why the same page can load fine when you bypass a proxy, then fail when you go through it.

Requests That Carry A Long Referrer

Some stacks will throw a header-size error when the referrer is huge. It’s less common than cookie growth, yet it still happens with long tracking parameters and redirect chains.

Common trigger	What grows	Fast fix
Too many site cookies	Cookie header	Clear that site’s cookies
Oversized token	Authorization header	Trim claims or shorten token
Extra proxy headers	Total header set	Remove unused added headers
Long tracking URLs	Referer header	Shorten links and redirects

Fix It In Your Browser First

When you’re just trying to load a page, the fastest wins come from shrinking what your browser sends. These steps change headers right away, without touching the server.

1. Open a private window — Load the page in a private or incognito window to test a clean cookie jar.
2. Clear site cookies — Remove cookies for the single site, not your whole browser, then reload.
3. Try a different browser — A second browser tests a separate cookie store and extension set.
4. Disable extensions — Turn off privacy tools, ad blockers, and request modifiers, then retry.
5. Cut the URL down — Remove long query strings in the address bar, then load the base path.

When clearing cookies fixes it, you’ve learned the root cause: the Cookie header was too big for that server’s limit. The long-term fix is on the site side, not in the browser.

Fix The Root Cause For Site Owners

Deeper fix: treat this as a data-budget issue. Your app is sending too much identity or state in headers. Raising limits can reduce outages, yet it can also hide a problem that keeps growing.

Slim Down Cookies Without Breaking Sessions

Start by listing what cookies your site sets. Browser devtools shows them, and most CDNs can log them too. Look for large values and long lifetimes.

• Move bulky data server-side — Store preferences and experiment payloads in your database or cache, then keep cookies as short IDs.
• Set tight scopes — Use the narrowest Domain and Path that still works, so you don’t send cookies to every endpoint.
• Expire dead cookies — Remove old names you no longer read, so they don’t linger in browsers for years.
• Cap cookie count — Keep the number of cookies low. Many small cookies still add up.

Trim Tokens And Claims

If the Authorization header is the issue, measure token size in bytes. Then audit the claim set. Claims that are never used in your app still count against header limits.

• Drop unused claims — Keep only what the app reads during the request.
• Use short identifiers — Send an ID and fetch detail data server-side.
• Watch nested groups — Group membership and role lists can explode in size fast.

If you need to pass a large identity payload between services, a signed reference token plus a shared lookup can be far smaller than shipping the whole identity on each hop.

Audit Proxy-Added Headers

Many stacks add headers for tracing and security. That’s fine when they are controlled, named well, and bounded in size. It gets messy when every hop adds a new header and nothing ever gets removed.

1. List what each layer adds — CDN, WAF, ingress, reverse proxy, gateway, app.
2. Remove what you don’t use — Keep required security headers, drop debug headers in production.
3. Cap verbose fields — Long user-agent strings and long forwarded chains can grow quickly.

Server Limits That Often Trigger This

Sometimes your app is fine and the limit is simply low for your current reality. You can raise header limits on the edge proxy, the web server, or the gateway. Do it with intent, and keep the increase as small as you can.

Raising limits has a cost. Bigger buffers use more memory per connection and can widen the blast radius of abusive requests. That’s why the better fix is still “reduce header size,” with server tuning as the safety net.

Nginx Buffer Settings

Nginx reads request headers into buffers. The core directives that control this are client_header_buffer_size and large_client_header_buffers. Long cookies are a common reason to raise them.

These snippets show the shape of the change. Adjust values to match your traffic and security posture.

http {
  client_header_buffer_size 4k;
  large_client_header_buffers 4 16k;
}

Apache Header Field Size Limits

Apache has a directive that limits the size of a single request header field: LimitRequestFieldSize. If your clients send large cookies or a large Authorization header, this limit can be the bottleneck.

  LimitRequestFieldSize 16384

IIS Header Limits

On IIS, Request Filtering lets you set per-header limits using headerLimits. This is useful when a single header like Authorization hits a ceiling.

How To Diagnose Header-Size Failures

Fixes stick when you can point to the exact header that crossed the line. You don’t need fancy tooling to do that, just a clean capture and a place to measure bytes.

Reproduce With A Clean Baseline

1. Test in a private window — If it works there, cookies are the prime suspect.
2. Test the same URL with curl — A minimal request often succeeds, which proves the page itself is fine.
3. Add headers back one by one — When a header triggers failure, you’ve found the offender.

Measure The Real Header Size

When you have access logs or gateway logs, log request header size if your stack supports it. Some gateways will show a “request length” value for the header block. Apigee also clearly documents a TooBigHeaders fault when total header size crosses its limit.

On the client side, devtools can show cookie sizes per cookie, plus the total cookie header. For tokens, paste the raw header value into a byte counter and record the size before and after changes.

Separate Total Size From One Bad Header

RFC 6585 allows 431 for two cases: the total set of headers is too large, or one header field is too large. Your fix depends on which case you hit. One oversized cookie calls for a cookie redesign. Many mid-sized headers can point to proxy fan-out, lots of cookies, or verbose tracing headers.

Prevention Habits That Stop Repeat Outages

Once you clear the outage, you want guardrails. The goal is simple: treat headers as a scarce resource and keep a budget.

• Set a header budget — Pick a maximum header size for normal requests and test it in CI.
• Cap cookie payloads — Use small IDs, short names, and short lifetimes for non-essential cookies.
• Watch identity growth — Keep JWT claims tight and avoid embedding long group lists.
• Keep proxy headers tidy — Remove debug headers and cap forwarded chains.
• Document limits per layer — Record CDN, proxy, gateway, and app limits so you know the smallest ceiling.

If you want to share a single reference with your team, link them to the standard definition of 431 in RFC 6585 and the practical notes in MDN’s 431 page. Those two pages set the ground truth.

When you treat headers like a budget, the status code turns from a mystery outage into a predictable limit you can manage right now.