This is a followup to this question, where I was offered the choice between making a cookie and using localStorage
to keep a variable over several sessions. Can someone give me the pros and cons of both, and a recommendation of which one to choose?
-
1This might be seen as a duplicate... – Denys Séguret Jan 10 '13 at 20:41
-
Flagged as duplicate of http://stackoverflow.com/questions/3220660/local-storage-vs-cookies – praseodym Jan 10 '13 at 20:42
-
Cookies are obsolete in my opinion. They always were painful to use. The new localStorage specification was built to avoid their problems. Cookies were designed before the era of ajax and are most useful for server side reading. – Denys Séguret Jan 10 '13 at 20:43
-
1@dystroy Can you access localStorage without JavaScript? Cookies can be written and read server-side without any JavaScript support whatsoever. – Blazemonger Jan 10 '13 at 20:50
-
1@Blazemonger Look at the tags. I suppose the variable is to be used client side. – Denys Séguret Jan 10 '13 at 20:56
4 Answers
I'd go with localStorage.
PROS
- Fast and easy read/write access to your data
- Your data does not get transferred to server along with every request which reduces a load
- Key-Value pair fashion
CONS
- Not supported in old browsers
- Can store up to 5 MB of data per domain
When it comes to cookies, they can be useful from time to time. Shopping cart is one scenario where cookies can be pretty useful when you want to restore shopping cart items after user closes his browser/session. But, do not store too many cookies because they get transferred to the server with every request you make (it includes AJAX requests as well). This can cause dramatic bottlenecks when/if your site becomes popular and gets many thousands/hundreds of thousands of hits per hour/day. Think about it.
Hope it helps.

- 731
- 3
- 9
-
3
-
1
-
I've updated my comment after I realized what I said. Thanks for observation, though. – semir.babajic Jan 10 '13 at 20:46
-
It's an important point because it basically means that in 2013 cookies should be a beast of the past. – Denys Séguret Jan 10 '13 at 20:46
-
Agree, but not entirely... Cookies can be pretty useful in certain scenarios, and do not forget that server side languages rely on cookies to maintain session, so they cannot become a matter of past that easy. – semir.babajic Jan 10 '13 at 20:48
-
-
1let alone cookies are like 4kb each limit with ~20 cookies per domain. – Fabrício Matté Jan 10 '13 at 20:50
-
Yes, I think that 5 MB is a con. Back in very early 1990s, 512 KBs was considered as a mammoth amount of memory. Blah, blah... If we're seriously thinking to abandon desktop and move applications we use to web, do you still think 5MB of local data will be enough for everything? Think twice, please. – semir.babajic Jan 10 '13 at 20:55
-
@semir.babajic It's a limit (that I personally appreciate because I'm a user too), but it can't be seen as a con of localStorage **compared** to cookies. – Denys Séguret Jan 10 '13 at 20:57
-
The 5MB limit is only a recommendation by the whatwg, not a specification. In the future, it could easily be increased. http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html#disk-space-0 – Philipp Jan 10 '13 at 20:59
-
Partially agree, but, I'm strongly convinced that this limit will grow in next few years. Transition from desktop to web is rapid, and is faster than ever. – semir.babajic Jan 10 '13 at 20:59
Points not yet mentioned by others are in bold:
- Cookies are sent to the server with every page requests, localStorage is not. That means:
- No unnecessary data transfer when you only need it on the client-side
- But when you need the value on the server, it needs to be transfered with an additional XmlHttpRequest after the page has loaded
- localStorage has a much larger capacity
- many browsers which implement localStorage don't have an option for disabling it, or have this option much better hidden than the option to block cookies, so less users disable it (many people who know about cookies don't even know that this feature exists).
- In my opinion, localStorage has a much easier to use API
- localStorage has no expire-header (but this can be emulated easily by adding an additional expire-date to the data and processing it manually)
By the way: don't forget about sessionStorage. The API is the same, and for many cases it's more appropriate than the persistent localStorage

- 67,764
- 9
- 118
- 153
I would just lay out 4 points that come to mind:
- localStorage doesn't travel with every request. It stays on the cient side (that's good, leaner requests)
- Has bigger size limitation than a Cookie (you can store more)
- Easier API to get/set values (IMO)
- The values stored in localStorage are not communicated to the server. If you need to be aware of the values stored on the server-side, then use a cookie.
You decide what's best for your scenario.

- 63,293
- 14
- 100
- 115
localStorage
is newer, part of HTML5 and older browsers may not support it. It's also just client side, meaning your server will never see it unless some client side code explicitly sends it to the server. The interface is very easy to use, and it's very fast.
Cookies are universally supported, and get sent to the server with each request automatically. But the cookie values can be accessed by both client and server with no extra work. The interface to manage cookies form JavaScript is incredibly obtuse with some library help.
If the value only needs to be local, and old browser support isn't a concern, use localStorage
.

- 178,991
- 47
- 309
- 337
-
"Older browsers *may* not support".. don't guess, know. http://caniuse.com/#feat=namevalue-storage – Lukas Liesis Jul 20 '16 at 05:56