Cookie, localStorage, and sessionStorage are all the simple data storage ways for client-side storage. Cookie is more like an old school way to handle the simple data stored on the client-side. In HTML5, web storage, such as localStorage or sessionStorage is introduced and it’s also easier to use.
Cookies
- Persistence: user can set expiration time for each cookies.
- Storage: there’s only about 4KB space for entire cookie data.
- Traffic: data needs to be sent back to the server for all the HTTP requests, which increases the traffic between client and server.
- Works for old browsers.
localStorage
- Persistence: data exist until it’s deleted
- Storage: available space increase to around 5 MB
- Traffic: less traffic because not all of the HTTP requests need to send data back to the server
- Domain: data only stays in the same domain, which means if data is stored on website A, next time it can only be accessed on website A. To be clear of the domain used here, it means the same website field. For example, whichever different posts or different personal pages in Facebook that you are browsing are all under facebook.com. As a result, those pages are all under the same domain.
sessionStorage
sessionStorage is similar to localStorage. The only difference will be the persistence of the data. For sessionStorage, once user leaves the domain, such as closing the tabs or windows, the sessionStorage is emptied.
How to use localStorage and sessionStorage?
Both localStorage and sessionStorage use key-value pair and their syntax are similar. Followings are the examples.
Syntax
//To store the data:
localStorage.setItem(“key”,”value”);
//To retrieve the data:
localStorage.getItem(“key”);
//To update the data (the same as to store the data):
localStorage.setItem(“key”,”value”);
//To remove one entry:
localStorage.removeItem(“key”);
//To clear all the data:
localStorage.clear();
Top comments (8)
Nice post, I just missed some security considerations:
Just don't use localStorage or sessionStorage for sensitive data (like JWT tokens), both are vulnerable to XSS attacks.
Cookies, besides their limitations, have a much more mature model for sensitive data (If you use the correct flags like httpOnly, https and sameSite). This is the only point where you should use it instead of localStorage/sessionStoreage.
That's a really good point!
Consider security issues, those sensitive data should not stay in front-end area because people can have access to it. The best way I feel would be to store those data in the database but not client side storage.
Nice post. A small addition to it
In most cases this is true, but you can use
fetchAPI to prevent this:On the other side if the browser supports
fetchit is better to usesessionStorageorlocalStoragefor client-side storage, and use cookies only for passing data to the server (for example for authentication).Cookies and localStorage/sessionStorage can be used for completely different purposes.
You compared apples to oranges. You can't make decisions on the server side based on localStorage, only with cookies.
If you treat the question as just about how an app stores local information, then they're comparable.
It's more like: if you need the server to be involved without rolling your own system, use cookies, else use *Storage.
Hi,
I strongly recommend the reading of Please Stop Using Local Storage. While localStorage is a great idea, it has flaws (not secure + can only stores strings + can’t work offline + generally limited to 5 MB of storage data) and should be avoided in favor of:
Like the article states, localStorage remains useful in a specific use case:
you can also save and store data like this
localStorage.key = "value";
You can, but is a better practice to use getters and setters. One of the most commont things I have to fix in legacy code are issues related with property mutations like that.