Skip to content
Menu

Too many cookies can break your site with a 400 error

One cookie per item looks harmless. On a community platform it reached 83 cookies for a single visitor, sent with every image and script, and heading for the limit where servers answer 400 Bad Request.

What the browser sent, on every request

Cookie: item_5012=…; item_5013=…; item_88=…83 cookies · about 4.5 KB← on every image, style and scriptabout 55 requests × 4.5 KB ≈ 250 KB uploaded per visitthe server limit (nginx default)a header above 8 KB → 400 Bad Request

What we found

On a community platform, a feature created one cookie for every item a visitor interacted with. Each new interaction added another. The most active visitor we checked was carrying about 83 cookies, around 4.5 KB, and the number only went up.

Nobody had noticed, because nothing was broken yet. That is exactly the problem: this kind of defect hurts the most engaged visitors first, and it gets worse the more they use the site.

Why it matters

  • Cookies travel with every request to your domain, not only with the page. On a home page with about 55 requests, 4.5 KB of cookies means around 250 KB uploaded per visit, on the slowest side of a mobile connection.
  • Browsers keep a limited number of cookies per domain and delete the oldest ones without warning. A feature that relies on those cookies starts forgetting what the visitor did.
  • Servers limit the size of request headers. With the default nginx settings, a header line above 8 KB is refused with 400 Bad Request. At this rate, the most active visitors would reach that limit first and see an error page instead of the site.

How to check your site

  • Open your site in Chrome, press F12, go to Application, then Cookies, and count the cookies for your domain after using the site for a few minutes.
  • Look for names that end in a number or an identifier, such as item_5012. That pattern means one cookie per thing.
  • In the Network tab, open any request and look at the size of the Cookie request header.

How we fixed it

We replaced the cookies per item with a single visitor cookie, and moved the memory of what each visitor did to the database, where it already partly lived.

Stopping new cookies was not enough, because the active visitors already had dozens of old ones valid for a year. On each visit, the site now moves up to 40 old cookies into the database and only then deletes them, so nobody loses their history or can repeat an action twice.

One detail decided whether the fix worked: the code treated "this cookie exists" as "the visitor already did this". With a single cookie, that test would have marked everything as already done for anyone who had clicked once. The check had to change together with the cookie.

The rule

Never create one cookie per item. Keep one cookie that identifies the visitor, and keep the list of items on the server.

Want us to check this on your site?

Get in touch