400 Bad Request: Request Header Or Cookie Too Large - Fix It

You reload the page and instead of your site you get a blunt "400 Bad Request" with a line underneath it: "Request Header Or Cookie Too Large." No stack trace, no plugin name to blame - just a dead stop before your app even runs. Here's what's actually happening and how to clear it for good.

What this error actually means

A 400 is different from the 500-series errors you're used to chasing. It's not your PHP code, your database, or a crashed process. It means the web server rejected the request before it ever reached WordPress or your application, because the HTTP headers attached to that request were bigger than the server is configured to accept.

The most common culprit inside that header block is the Cookie header. Browsers send every cookie set for a domain on every single request to that domain - HTML pages, images, CSS, AJAX calls, all of it. If your site (or a subdomain sharing the same root domain) has piled up dozens of cookies over time, that header can balloon past the server's limit.

Where the limit lives

Common causes

• Too many WordPress plugins setting cookies - A/B testing tools, consent managers, affiliate trackers, and cart plugins each add their own cookie, and they rarely clean up old ones.
• WooCommerce cart/session cookies stacking up - abandoned sessions and coupon-tracking cookies accumulate, especially on sites with long visitor sessions.
• A broken login loop - if wp-admin keeps failing to authenticate, WordPress can keep issuing new wordpress_logged_in_ cookies without clearing the old ones.
• Subdomain cookie sharing - if cookies are scoped to .yourdomain.com instead of a specific subdomain, every subdomain's cookies get sent together, multiplying the header size.
• Stale auth cookies from a dev/staging environment - especially after a migration where the domain didn't change but the cookie secret did.

Fix it as a visitor (fastest path)

If it's happening to you as a single user, this is almost always a client-side fix:

1. Clear cookies for just that domain - in Chrome: Site settings → Cookies → See all site data, search your domain, delete everything.
2. Try an incognito/private window. If the site loads fine there, it's 100% a stale-cookie problem, not a server bug.
3. If you're a logged-in WordPress admin, log out, clear cookies, then log back in rather than just refreshing.

That resolves it for one visitor. If it keeps happening to multiple visitors, or every time after login, the fix needs to happen on the server.

Fix it on the server

Nginx

Raise the header buffer size in your server block or nginx.conf:

large_client_header_buffers 4 16k;

Then test and reload:

nginx -t && systemctl reload nginx

This buys you headroom, but treat it as a safety margin, not a license to let cookies keep growing - a header that's genuinely 16KB+ usually means something upstream is misbehaving.

Apache

In your vhost or .htaccess (if AllowOverride permits it):

LimitRequestFieldSize 16380
LimitRequestFields 200

On cPanel/WHM servers running Apache with Nginx as a reverse proxy (common on shared hosting), you may need to raise the limit on both layers - Nginx will reject it first if its buffer is smaller.

LiteSpeed / OpenLiteSpeed

In WHM: Service Configuration → LiteSpeed Web Server Configuration → Tuning, increase the request header size, then restart LiteSpeed from WHM's service manager.

Fix the root cause in WordPress

Raising server limits treats the symptom. If cookies are actively growing without bound, find what's writing them:

• Open DevTools → Application → Cookies for your domain and sort by name. Anything you don't recognize, search the plugin slug that matches it.
• Deactivate consent-management, A/B testing, or heatmap plugins one at a time and watch the cookie count drop.
• Check wp-config.php for a COOKIE_DOMAIN constant scoped wider than it needs to be (e.g. set to .example.com when the site only lives on www.example.com).
• If WooCommerce is involved, confirm session cookies are being cleaned up - old, abandoned cart sessions shouldn't persist indefinitely.

Prevention

• Audit your cookie-setting plugins every few months - most sites only need one consent tool, not three overlapping ones.
• Scope cookies to the exact subdomain that needs them, not the whole root domain, unless you specifically need cross-subdomain sharing.
• Set a reasonable header buffer size proactively on VPS/dedicated servers rather than waiting for a visitor to report a 400.
• If you're behind Cloudflare, keep an eye on total cookie payload - Cloudflare's own limit is generous, but your origin server's limit is usually the real bottleneck.