How to Fix 400 Bad Request Header or Cookie Too Large

What “400 Bad Request Header or Cookie Too Large” Actually Means

A 400 Bad Request response means the server will not process the request because something about it is invalid or too large. When the message specifically mentions header or cookie too large, the issue is usually not the page content itself. The problem is the metadata attached to the request before your site even starts rendering.

Every browser request includes headers. Those headers may contain cookies, authentication data, language preferences, user-agent details, tracking values, referrer information, and more. If that pile of metadata gets too big, one of the systems handling the request may reject it. That system could be:

• Your origin web server
• A reverse proxy like NGINX
• An Apache server
• A CDN or security layer
• A load balancer
• An app framework or middleware layer

Sometimes the “correct” status code would be 431 Request Header Fields Too Large. But plenty of stacks still return a plain old 400, which is why this error can feel annoyingly vague.

Why This Error Happens

1. Your cookies got too big

This is the classic cause. Websites use cookies for sessions, preferences, carts, experiments, analytics, and marketing. One cookie may be harmless, but dozens of them can pile up. If the total cookie payload gets large enough, the browser sends a request that the server or intermediary refuses.

This is especially common when developers store too much data in cookies, such as:

• Large JSON blobs
• Overstuffed session data
• Long JWTs or identity tokens
• Duplicate tracking cookies
• Cart or personalization data that should live elsewhere

2. A single header is oversized

Sometimes it is not the cookie count. It is one giant header. A huge Cookie header is the usual suspect, but it can also be a very long URL in the request line, a massive authorization header, or an inherited chain of forwarding and custom headers from multiple proxies.

3. Your app sits behind more than one gatekeeper

Even if your origin server is fairly generous, your request still has to make it through every layer in front of it. A CDN, WAF, reverse proxy, or load balancer may have its own header limits. That means your app may be perfectly happy with a request that never actually reaches it. Charming, right?

4. Corrupted or stale cookies are making things worse

Not every broken cookie is enormous. Sometimes an expired, malformed, or duplicated cookie causes the request to fail in a way that looks like a size problem. Login loops are a common sign. If the site repeatedly writes new session cookies without cleaning up the old ones, the browser can end up sending a messy cookie jar that the server does not enjoy.

5. Marketing and tracking parameters created a monster

Long URLs with stacked campaign parameters, redirects, and personalization values can bloat the request line and related headers. This gets even uglier when those values are copied into cookies for later use. Suddenly your analytics strategy has become a networking problem.

How to Fix It as a User

If you are just trying to access a site and do not control the server, start with the simple fixes. In many cases, this error disappears after you clean up the site’s cookies and reload the page.

Clear cookies for the affected site

This is the first move because it solves the most common cause. You do not always have to nuke your entire browser history like you are fleeing the scene of a digital crime. Clearing site-specific cookies is often enough.

Focus on removing cookies for the exact domain that is failing, then reload the page and sign in again if needed.

Clear browser cache too

Cache is not usually the main villain in a “cookie too large” error, but stale site data can make recovery slower or weirder. Clearing cache along with cookies helps reset the relationship between the browser and the site.

Try an incognito or private window

If the page loads in a private session, that is a giant clue. It usually means your normal profile has stored cookies, extensions, or other site data causing the bad request.

Trim the URL if it looks ridiculous

If the address bar is stuffed with long query parameters, try removing the extra tracking junk after the question mark, especially if the URL came from an email campaign, ad click, or a redirect chain. Save the clean version and reload.

Disable browser extensions temporarily

Some extensions inject or modify headers, add tracking behavior, or interfere with site sessions. Test with extensions off if the error persists.

Try another browser or device

If the same page works elsewhere, the problem is probably local to one browser profile. If it fails everywhere, the site owner likely needs to fix something server-side.

How to Diagnose It as a Developer or Site Owner

If you manage the site, do not stop at “tell users to clear cookies.” That treats the symptom, not the cause. You want to figure out which header is bloated, where the request is being rejected, and why the size keeps growing.

Inspect the failing request in DevTools

Open the browser’s Network panel and reproduce the error. Look at the request headers, especially:

• Cookie
• Authorization
• Referer
• X-Forwarded-For and other proxy headers
• Long custom application headers

If the cookie header looks like a Thanksgiving buffet, you found your culprit.

Check what your application is setting

Review every Set-Cookie response header your app emits. Ask a blunt question: does this cookie actually need to exist? If the answer is “maybe,” that is usually a polite way of saying “no.”

Review logs at every layer

If you use NGINX, Apache, a CDN, or a load balancer, check logs there too. The request may be rejected before it ever reaches your application. A frontend proxy might log a bad request while your app logs absolutely nothing, which is a clue all by itself.

Reproduce after login, redirect, or feature flag changes

This error often appears after authentication changes, new analytics tags, A/B testing tools, cart updates, or SSO rollouts. In other words, it tends to show up right after someone says, “This is just a small change.”

Server-Side Fixes That Actually Work

Sometimes the right fix is to reduce cookie and header size. Sometimes you also need to raise server limits carefully. The keyword there is carefully. Raising limits without cleaning up the underlying problem is like buying bigger pants instead of admitting the cookies are winning.

Fix the root cause first: shrink what you send

• Keep session cookies lean
• Do not store full objects in cookies
• Remove duplicate or legacy cookies
• Stop serializing carts, preferences, or feature states into cookies
• Shorten or redesign oversized tokens when possible
• Use server-side session storage for session data
• Use localStorage or sessionStorage only for non-sensitive, client-only state that does not need to be sent with every request

NGINX

NGINX commonly throws this error when request headers or a single cookie line overflow its configured buffers. The usual knobs are client_header_buffer_size and large_client_header_buffers.

Adjust values based on your environment, then test carefully. Bigger is not automatically better. Oversized buffers can hide bad application behavior and may increase resource usage.

Apache

Apache gives you control over maximum request line size, field size, and field count. The directives most relevant here are LimitRequestFieldSize, LimitRequestLine, and sometimes LimitRequestFields.

If you raise these values, do it because you understand your traffic, not because a forum thread told you to turn every dial to maximum and hope for spiritual renewal.

AWS Application Load Balancer

If your app sits behind an ALB, remember that header limits can be enforced there too. You may be debugging your app for hours when the load balancer is actually the one rejecting the request.

CDNs and reverse proxies

Cloud platforms and CDNs may impose their own header rules. Some can strip or remove problematic cookie headers, while others simply reject the request. Check platform-specific docs and rules to see whether you can remove unnecessary cookies before the request reaches origin.

Fastly, Cloudflare, and similar layers

If your stack uses an intermediary, confirm whether cookies are forwarded at all, whether cache varies on cookies, and whether oversized headers are modified, dropped, or rejected. These systems are helpful until they become your surprise co-author.

How to Prevent the Error from Coming Back

Audit every cookie on the domain

List all cookies by name, purpose, size, expiration, and owner. You may discover that five different tools are each setting “just one tiny cookie,” which together become a respectable pile of chaos.

Scope cookies narrowly

Use the smallest practical domain and path. If a cookie only matters on /account, do not spray it across the entire site like confetti.

Keep authentication compact

If your auth cookies or headers are huge, rethink token design. Shorter identifiers plus server-side lookups are often cleaner than stuffing entire user state into a request.

Set expiration dates with discipline

Old cookies have a way of sticking around long after everyone forgets why they were created. Expire obsolete values and clean up migrations properly.

Watch third-party scripts

Ad tech, analytics tools, chat widgets, personalization suites, and testing platforms can all add cookies. Monitor what third-party code is doing before your headers turn into a junk drawer.

Test with realistic browser sessions

A clean QA browser profile can hide problems. Test with old cookies, long sessions, repeated logins, multiple redirects, and actual marketing URLs. Production users do not arrive with a pristine browser and a pure heart.

Field Notes: What This Error Looks Like in Real Life

In real-world troubleshooting, this error rarely announces itself in a neat, textbook way. More often, a team first notices it when a few users cannot log in, a checkout page fails after a redirect, or an admin area suddenly stops loading only in one browser. The first reaction is usually confusion because the site works for some people and completely breaks for others. That inconsistency is part of what makes the problem sneaky. The request may only fail after a session has accumulated enough cookies over time, so fresh testers cannot reproduce it right away.

One very common pattern shows up in sites that use multiple marketing and analytics tools. A user lands on a campaign URL packed with parameters, gets tagged by analytics scripts, enters a login flow, and then gets bounced through one or two redirects. By the time the browser reaches the destination page, the request carries old session cookies, new tracking cookies, and maybe an experiment assignment too. Nothing looks outrageous in isolation, but together the request starts traveling with a fully loaded suitcase. The site seems fine during development, then breaks in production after a real campaign drives real traffic with real baggage.

Another pattern appears after authentication changes. A team migrates to SSO, adds a larger token, or layers in feature flags and role data. Suddenly users with the most permissions are the first to fail. Why? Because their sessions often generate the biggest cookies or authorization headers. That is the maddening part: your power users, admins, and internal staff become the canaries in the coal mine because they carry the heaviest request metadata. In practice, the fix is usually not “raise every limit forever.” It is trimming what gets stored, reducing duplication, and pushing state back to the server where it belongs.

There is also the classic “works in incognito, fails in normal Chrome” mystery. This often turns out to be a browser profile stuffed with months of site data. A stale cookie collides with a new one, or a domain keeps accumulating leftovers from different app versions. Clearing cookies solves it instantly, which feels satisfying for about ten seconds. Then comes the important realization: if lots of users can hit the same issue, the browser was not the true root cause. It was just the place where the evidence piled up. The lasting fix comes from better cookie hygiene, leaner headers, tighter scoping, and testing that reflects how people actually use the site over time.

Conclusion

400 Bad Request: Request Header or Cookie Too Large sounds dramatic, but the diagnosis is usually practical. Your browser is sending more header data than one part of the stack is willing to accept. For users, the fastest fix is often clearing site cookies and retrying. For developers, the real win is reducing cookie bloat, inspecting request headers, and aligning limits across browsers, proxies, servers, CDNs, and load balancers.

In other words, do not just make the bucket bigger. First, stop pouring soup into your cookies.

SEO Tags