Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As web developers, we all learn that sessions help overcome the problems related to the stateless nature of HTTP. We create a unique session id, and send it to the browser -- and when the browser sends the same id back to us, we identify the user easily.

All this sounds pretty straightforward, and NOT so complicated to implement in any language.


Look at the following screenshots I took. These show the kinds of cookies popular websites store. It looks like they are storing multiple session IDs, or they are trying the hide the actual id by setting so many cookies, or, it is something very specialized security measures they're taking to prevent session hijacking and other related problems. Or, whatever.

Gmail (before login)

enter image description here

Gmail (after login)

enter image description here


enter image description here


enter image description here

(Don't worry, you can't steal my session -- it's stale and incomplete :))

So, my question is -- what purpose does this complicatedness serve? Please explain what these different cookies mean (in general), and for what purposes these are set. Lastly, hint on how I can do it (and whether I should) in my own apps.

One more question: In a lot of instances, the values in the cookies look like they are URL-encoded -- why so?

share|improve this question
up vote 20 down vote accepted
  1. Sometimes it's not practical to store certain data in a session table on the database. If certain data gets updated a lot then it could bog down the database a lot as well. If that's the case and the data's not too important, it might be better stored in a separate cookie.

  2. When (1) happens you have to deal with the 4kb-per-cookie limit, so storing all of the in-cookie session data in one cookie is a bad idea.

  3. It'd be nice to be able to store everything in the minimum number of cookies required, but project complexity concerns make this difficult. Some applications are developed by several teams. Sometimes what you see as one web server is actually a proxy that talks to several different clusters of web servers, routing different sections of the site to different clusters, each with their own set of cookies.

  4. Cookies are cheap. You're the exception to the rule - nobody looks in their cookie store to see how many cookies they have. And there is little performance benefit to trying to combine all of the client-side session data into as few cookies as possible.

share|improve this answer
I'm also the exception to the rule. – Michael Slade May 1 '12 at 14:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.