Skip to main content

Cookies vs Local Storage vs Session Storage

 

Why should we store data in the browser?

One of the key reasons to store data in the browser is performance. You can’t always wait for the server to send a response for every request. Sometimes it’s better to have some piece of information stored in your browser for quicker access. So basically, there are 3 ways to store data locally in the browser — Cookies, Local Storage and Session Storage.

Cookies

Cookies are the oldest and most common way of storing data. A cookie is basically some text-based information. It is usually set by a server, nevertheless it can also be set in the browser. The working is simple, each time a request is made from the browser, the browser automatically attaches the cookie along with it. Now the server receives the information that was set in the browser.

We can set an expiration time for the cookie that is being set. There’s only 4KB storage space allowed for the entire cookie data. Cookies are advantageous as they work in older browsers as well. A cookie can be accessible to every window in the browser.

If you want to set a cookie manually using your browser, you can type this piece of code in your browser dev console where  is the key and  is the value and then have a look at your Applications tab under Cookies to check if it set or not.

Cookie set in browser
Cookie being set

Common Use Cases

  • Authenticating logged in users — Whenever the user successfully signs in, the server sends a success response and also sets a cookie, so that whenever requests are sent in the future, the server recognizes that the user is signed in.
  • Identifying user state — For example in an e-commerce site, whenever the user adds a new item and refreshes the page, it automatically shows up the added item in the cart, with the help of cookies.

Web Storage

In HTML5 Web Storage such as Local Storage and Session storage were introduced. So, what has changed? The idea behind introducing these is to make storing and retrieving values easier on the client side. The data in these storages are generally stored in key-value pairs. One particular improvement was that the size of the storage was much better than cookies.

You can access the Web Storage values using Javascript. None of this data can be read by the server unlike the cookies, unless we manually pass them along with the request. In other words, you can consider this Web Storage as your small personal database present in your browser.

Local Storage and Session Storage have a lot of things in common, with only a few dissimilarities. Let’s have a look at both:

Local Storage

The Local Storage is a type of Web storage which like cookies is accessible on all windows in the browser. When it comes to the storage capacity, it can store upto 5–10 MB, which is much better when compared to cookies. And the values set in local storage never expires until and unless we manually remove them.

On your browser console use these commands to set, get, remove and clear Local Storage values.

Session Storage

The Session Storage has a lot of similarities to Local Storage, but the storage size is limited to 5MB. Also, the values stored gets automatically removed from the browser when you close the active tab. As the name suggests, the values are only available for that session.

On your browser console use these commands to set, get, remove and clear Session Storage values.

Image for post
Values set using local storage

Common Use Cases

  • An application’s light mode/dark mode can be stored here in the browser.
  • Likewise you can store the web application’s user customized data here. Say, choosing themes, layouts, etc.

Which one should you choose?

The answer to this depends on what is your exact use case. If you want your page to always hold some data that is not confidential, then you can use . If the server needs to know some information like authentication key, you should use cookies to store them.  can be used to store the state of interface, i.e., whenever you visit a page, customize it, visit another page and return to the same page, you would want to show the page how the user customized it. That’s a good use case for .

Conclusion

By now, I believe you know how each of these storages work and how they differ. I hope you’ll be putting this knowledge to use, when you are building your own application.

Thanks for reading! Happy coding!

Comments

Popular posts from this blog

How to use Ngx-Charts in Angular ?

Charts helps us to visualize large amount of data in an easy to understand and interactive way. This helps businesses to grow more by taking important decisions from the data. For example, e-commerce can have charts or reports for product sales, with various categories like product type, year, etc. In angular, we have various charting libraries to create charts.  Ngx-charts  is one of them. Check out the list of  best angular chart libraries .  In this article, we will see data visualization with ngx-charts and how to use ngx-charts in angular application ? We will see, How to install ngx-charts in angular ? Create a vertical bar chart Create a pie chart, advanced pie chart and pie chart grid Introduction ngx-charts  is an open-source and declarative charting framework for angular2+. It is maintained by  Swimlane . It is using Angular to render and animate the SVG elements with all of its binding and speed goodness and uses d3 for the excellent math functio...

Understand Angular’s forRoot and forChild

  forRoot   /   forChild   is a pattern for singleton services that most of us know from routing. Routing is actually the main use case for it and as it is not commonly used outside of it, I wouldn’t be surprised if most Angular developers haven’t given it a second thought. However, as the official Angular documentation puts it: “Understanding how  forRoot()  works to make sure a service is a singleton will inform your development at a deeper level.” So let’s go. Providers & Injectors Angular comes with a dependency injection (DI) mechanism. When a component depends on a service, you don’t manually create an instance of the service. You  inject  the service and the dependency injection system takes care of providing an instance. import { Component, OnInit } from '@angular/core'; import { TestService } from 'src/app/services/test.service'; @Component({ selector: 'app-test', templateUrl: './test.component.html', styleUrls: ['./test.compon...

How to solve Puppeteer TimeoutError: Navigation timeout of 30000 ms exceeded

During the automation of multiple tasks on my job and personal projects, i decided to move on  Puppeteer  instead of the old school PhantomJS. One of the most usual problems with pages that contain a lot of content, because of the ads, images etc. is the load time, an exception is thrown (specifically the TimeoutError) after a page takes more than 30000ms (30 seconds) to load totally. To solve this problem, you will have 2 options, either to increase this timeout in the configuration or remove it at all. Personally, i prefer to remove the limit as i know that the pages that i work with will end up loading someday. In this article, i'll explain you briefly 2 ways to bypass this limitation. A. Globally on the tab The option that i prefer, as i browse multiple pages in the same tab, is to remove the timeout limit on the tab that i use to browse. For example, to remove the limit you should add: await page . setDefaultNavigationTimeout ( 0 ) ;  COPY SNIPPET The setDefaultNav...