What is the maximum size of a cookie, and how many can be stored in a browser for each web site?
No more than 50 cookies per domain, with a maximum of 4 KB per cookie (or even 4 KB in total, see Iain's answer). On IE 6 it used to be 20 cookies per domain.
Generally it's recommended to preserve state on the server, and use cookies only for session tracking. They're sent along with every request, so they form an unnecessary overhead if the purpose is to keep session state around.
If you do want to keep state on the client, and you can use JavaScript to do it, there are options. Use the assorted storage API's directly or find a wrapper library that abstracts away the details.
Client-side storage options:
- localStorage: Firefox 2+, Chrome 4+, Safari 4+, Internet Explorer 8+. 5 MB per domain without user confirmation (but be aware that it is stored as UTF-16 so you may use two bytes per character).
- IndexedDB: Firefox 4+, Chrome 11+, Safari 10+, Internet Explorer 10+. 5 MB per domain without user confirmation, much more after confirmation (highly browser specific, check your browser for details).
Deprecated storage options:
- Flash 8 persistent storage: any browser with Flash 8+. 100 KB, more with user permission. Deprecated because Flash itself is deprecated.
- userData: Internet Explorer 5.5+. 64 KB per domain in the restricted zone, 128 KB per domain in the internet zone. Replaced by localStorage.
- Web SQL: Chrome & Safari only, it will never make it to other browsers because it was not possible to standardize it.
So, generally for client-side storage it depends on the use case:
- For session id tracking or for a few KB, use cookies.
- Up to 2 MB, localstorage delivers a solution across all common browsers.
- 2 MB and up, use IndexedDB (look for a good wrapper library).
Cookie Size Limits
If you want to support most browsers, then do not exceed 50 cookies per domain, and 4093 bytes per domain. That is, the size of all cookies should not exceed 4093 bytes.
Performance Thoughts
Cookies are sent on every request for a domain, this includes images. For arguments sake, lets say you have 30 resource on your website, and have 4093 bytes of cookies. That means the user is uploading 122Kb of data. So if I have a 1Mbit upload connection, that will take at least 1 second.
If you want to see the cookie test page I created, or read more about it check out Browser Cookie Limits.
Firstly, I suggest you don't worry about this issue. There is AMPLE room to serialize tons of identifiers to.
Secondly it's not stored by web-server but by web-domain — e.g., www.google.com and not the 100's of different physical servers that serve the Google domain.
Thirdly if you do have to worry know that there are two possible cookie headers. The sizes of these cookie headers are determined by the browser software limits.
Design Discussion
What you don't want to use the cookie header for is sending details about a client's session. E.g., don't try to stuff the email a client is typing into a cookie if you are building an email front-end. Instead you would send the client a cookie that represents his identity+session: you store all sessions data against this identity. You can store tens of identifiers (4–16 bytes) per cookie header and no one needs more than say 4 of these. The cookies data (as an integer) tends to be encoded to base64 which increases the byte-count.
Performance
Your browser sends a plethora of headers to a web-server. The cookie is just another 100-1000 bytes (mostly closer to 100). At both extremes it takes only a fraction of time to send these to the web-server — when placed into context of course. You should keep in mind that the web is built on text based protocols.