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;
client_header_buffer_size 4k;

Then test and reload:

nginx -t && systemctl reload nginx

The two directives do different jobs and both matter. client_header_buffer_size is the buffer nginx tries first for every request; when a header does not fit, it falls back to large_client_header_buffers, whose second value is the per-header ceiling. Raising only the first one does nothing for an oversized Cookie header, because a single header still has to fit inside one large buffer.

If nginx is a reverse proxy, that is only half the fix

This is the step most guides leave out, and it is why the error survives a config change that looked correct. When nginx sits in front of Apache, a Node app, or any upstream, it has a second set of buffers for the response side of that conversation - and the upstream sends the same large headers back. Raising the client buffers alone leaves the proxy leg untouched:

proxy_buffer_size   16k;
proxy_buffers       8 16k;
proxy_busy_buffers_size 32k;

On a cPanel server running Apache behind nginx, both layers have to be raised. Whichever limit is smaller is the one that rejects the request, so a generous Apache setting is worth nothing if nginx in front is still at its default.

Measure the header before you guess at a number

Rather than doubling values until the error stops, find out how big the header actually is. Log it:

log_format headers '$remote_addr $status $request '
                   'cookie_bytes=$http_cookie';
access_log /var/log/nginx/headers.log headers;

Or reproduce it from the command line with a cookie of a known size, which tells you the exact ceiling in one pass:

curl -sS -o /dev/null -w '%{http_code}\n' https://yourdomain.com \
     -H "Cookie: test=$(head -c 8000 /dev/zero | tr '\0' 'a')"

A 400 at 8 KB and a 200 at 4 KB puts the real limit between them. That turns a guess into a measurement, and it tells you whether 16k is headroom or barely enough.

Raising the buffers buys you room, but treat it as a safety margin rather than a licence to let cookies keep growing - a header that is genuinely past 16 KB nearly always 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.

Related errors people hit alongside this one

A 400 rejects the request before your application runs, which puts it in the same family as the connection-level failures rather than the 500s. If the symptom you are actually seeing is different from the one on this page, Chrome's error codes decoded maps each message to the layer that produced it. The two nearest neighbours are 413 Request Entity Too Large, which is the same class of limit applied to the request body instead of its headers, and ERR_CONNECTION_RESET, which is what an oversized request looks like when a security layer kills the connection instead of answering with a 400.

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.