If you have seen “400 Bad Request – Request Header Or Cookie Too Large” in your browser, it means Nginx rejected the request before it ever reached PHP. The combined size of the cookies being sent back to the server exceeded the buffer Nginx allocates for request headers, and Nginx refused to process it.
This is different from a generic 400 Bad Request, which can have several causes. The “Request Header Or Cookie Too Large” variant tells you exactly what the problem is: cookies.
Why this happens
Every HTTP request your browser makes includes all cookies set for that domain. Cookies are sent as a single
Cookie
header, and every cookie – whether it was set by WordPress, a plugin, WooCommerce, an analytics script, or an advertising platform – gets concatenated into that one header value.
Nginx allocates a fixed amount of memory to read request headers. The relevant directive is
large_client_header_buffers
, which defaults to 4 buffers of 8KB each. If the
Cookie
header alone exceeds the buffer size, Nginx returns a 400 immediately.
The problem is cumulative. No single cookie is usually the culprit. It is the combination of all of them.
What typically pushes cookies over the limit
WordPress authentication cookies
WordPress sets several cookies when a user logs in:
wordpress_logged_in_*
,
wordpress_sec_*
, and
wp-settings-*
. On their own these are not large, but they form the baseline that everything else adds to.
WooCommerce session cookies
WooCommerce stores cart and session data in cookies. On stores with many product variations or custom cart logic, these cookies can be substantial. WooCommerce does support server-side session storage, which keeps cookies smaller – but many configurations still default to cookie-based sessions.
Caching and security plugins
Some caching plugins set cookies to track whether a visitor should receive a cached or dynamic page. Security plugins may set cookies for bot detection, session validation, or two-factor authentication state. Each plugin adds its own cookie, and they add up.
Third-party scripts
This is often the biggest contributor. Analytics tools, advertising platforms, social media widgets, chat widgets, A/B testing tools, and consent management platforms all set cookies via JavaScript. These cookies are sent to your server on every request, even though your server does not use them.
A site running Google Analytics, Facebook Pixel, a chat widget, and a consent banner can easily have 10+ third-party cookies being sent on every request. Combined with WordPress and plugin cookies, the total can approach or exceed 8KB.
Subdomains sharing a parent domain cookie scope
If cookies are set on
.example.com
rather than
www.example.com
, they are sent to every subdomain – the main site, staging, admin panels, APIs. This multiplies the problem across subdomains that were never intended to receive those cookies.
How to confirm cookies are the cause
Clear cookies and retry
The fastest test. Clear all cookies for the domain in your browser and reload the page. If the error disappears, cookies were the cause. The error will likely return over time as cookies accumulate again, which tells you the underlying issue still needs to be addressed.
Check the cookie size in developer tools
Open your browser’s developer tools, go to the Application tab (Chrome) or Storage tab (Firefox), and look at the cookies for your domain. Add up the sizes. If the total is approaching 8KB, that is your problem.
Alternatively, in the Network tab, find a request to your domain and look at the
Cookie
header in the request headers. The raw size of that header value is what Nginx is checking against its buffer limit.
Test in an incognito window
An incognito or private browsing window starts with no cookies. If the site loads fine in incognito but fails in your regular session, the accumulated cookies in your regular session are confirmed as the cause.
How to fix it
For visitors currently experiencing the error
Clear cookies for the affected domain. In Chrome: open developer tools, go to Application > Cookies, right-click the domain, and select Clear. In Firefox: go to Settings > Privacy & Security > Cookies and Site Data > Manage Data, find the domain, and remove it. The site will load again immediately.
This is a temporary fix. If the cookies accumulate again, the error will return.
Audit and remove unnecessary cookies
This is the actual fix. Review every cookie being set on your domain:
Deactivate plugins you are not using. Every active plugin that sets cookies adds to the total, even if you are not actively using the plugin’s features.
Check third-party scripts. Open the Application tab in developer tools and look at which cookies are being set by third-party JavaScript. Remove any third-party integrations you do not need. For the ones you keep, check if they offer a cookie-free or minimal-cookie configuration.
Move WooCommerce sessions server-side. If you run WooCommerce, check whether session data is being stored in cookies or in the database. Database-backed sessions keep the cookie payload small.
Scope cookies correctly. If you or a plugin are setting cookies on the bare domain (
.example.com
), they will be sent to every subdomain. Set cookies on the most specific domain possible (
www.example.com
) to avoid sending them where they are not needed.
Increase the buffer size
If reducing cookie size is not practical – for example, if you run a complex WooCommerce store with integrations that require cookies – the server-side fix is to increase
large_client_header_buffers
in Nginx.
A common adjustment is:
large_client_header_buffers 4 16k;
This doubles the default buffer size from 8KB to 16KB per buffer. On managed hosting, this is a server-level configuration change – contact your hosting provider to request it.
Increasing the buffer is a valid fix, but it treats the symptom. If your cookies are large enough to hit the default limit, they are likely larger than they need to be. Address the cookie bloat alongside the buffer increase.
Why this error often affects only some visitors
Not all visitors have the same cookies. A first-time visitor has no cookies for your domain and will never see this error. A returning visitor who has logged in, added items to a cart, accepted a cookie consent banner, and visited pages tracked by multiple analytics tools will have significantly more cookies.
This is why the error can be difficult to reproduce. The site appears to work fine in testing – because testing often starts with a clean session – while a subset of real users with accumulated cookies hits the limit.
If you are seeing this error in Google Search Console, it likely means Googlebot or another crawler encountered a scenario where cookies were set during crawling. This can happen if your site sets cookies on the response (via
Set-Cookie
headers or JavaScript) and the crawler retains them across subsequent requests.
Related errors
- 400 Bad Request in Nginx – the general 400 error, which covers additional causes beyond cookies including malformed headers and invalid URIs
- 413 Request Entity Too Large – a different size limit, this one on the request body rather than headers, typically triggered by file uploads
- 404 Not Found in Nginx – often confused with 400 errors by non-technical users, but an entirely different issue related to missing resources or misconfigured rewrite rules
- 504 Gateway Timeout – another Nginx error, but caused by the backend taking too long rather than anything wrong with the request itself
Summary
The “Request Header Or Cookie Too Large” error is Nginx rejecting a request because the cookies being sent exceed the header buffer size. It most commonly affects WordPress sites with many plugins, WooCommerce stores, and sites running multiple third-party scripts that each set their own cookies. Fix it by auditing and reducing the cookies set on your domain, moving session data server-side where possible, and removing third-party integrations you do not need. If the cookie payload is legitimately large, increase
large_client_header_buffers
in Nginx as a server-side accommodation.