For most web browsers, the web storage API provides a mechanism to store key-value pairs in the browser. It’s generally divided into localStorage and sessionStorage, and the main difference between the two is how long the browser stores the data. With sessionStorage, the data is removed once the session ends or the browser closes. Data in localStorage, though, persists until it is cleared.
A common real-world example of localStorage is the game Wordle. Once you type in a word and press Enter, the values are stored in localStorage. If you close and reopen the Wordle page on the same device, you’ll get the same words you already tried. The storage is reset at the end of the day.
The daily answer is also stored in localStorage, so that you can play the game offline after opening the page.
The localStorage feature can prove helpful in a number of use cases. This article will explain more about localStorage and how it works, so that you can use it with your applications.
There are a number of useful features in localStorage, including the ability to store user information and to allow you to work offline as needed.
As part of the web storage API in web browsers, localStorage works similarly to cookies. However, it can store a larger amount of data. The storage available in Google Chrome is 5 MB maximum per domain, while Opera’s localStorage holds 3 MB but can be increased.
Because the internet may not be consistently accessible everywhere, localStorage enables you to take your work offline, just like with Wordle.
You can also store the state of your web page, even though HTTP is stateless. Say you only wanted to use the Solarized Dark theme on the Alligator.io site. Using localStorage, you wouldn’t have to change the theme every time you reopen the browser and visit the site.
Using localStorage offers a number of benefits, including the following:
A widespread use of localStorage is to store access tokens, such as JWT tokens, on the user’s side so the user stays logged in for a specified amount of time.
This is insecure and should never be done, since it’s accessible using JavaScript on the same domain. This means any JavaScript code running on the page could access the storage, leaving your application vulnerable to cross-site scripting (XSS) attacks.
Applications also frequently use third-party scripts to get analytics or ads, and if even a single script is compromised, you risk being hacked.
For more information, check this article about safer ways to store auth tokens.
Following are some common use cases for localStorage.
If a user is filling out a long form, localStorage can be helpful in storing partial data. Even if the internet is disconnected between beginning the form and submitting it, the user won’t lose their inputs and can continue from where they left off.
According to a 2022 analysis by Portent, customer conversion rate can increase by 2.5 times when your page loads in one vs. five seconds. Building a slow website is not an option anymore. But when an end user asks for specific data and the request has to travel across the wire with associated latency, caching can be a life-saver. The localStorage can be used to cache a website or to store static data to show the client information even when the page is offline, then fetch necessary data when the internet reconnects.
Using localStorage, a user can open a timer website on a browser tab, start the timer, then open another tab of the same website and sync the timer between both tabs. You can also sync music or your video player between tabs.
You can use localStorage to store a pre-populated version of your application. When a user visits your application, they immediately see something on the screen, then your application can make calls to the backend to fetch new information. E-commerce sites often use localStorage to store items the user has viewed and other user-specific data.
You have a few methods to choose from when performing operations on localStorage. They are:
Following are more details on each one.
The setItem method is used to store values to localStorage. This method takes in two parameters: a key and a value. The key is used to fetch the data later.
Here’s a simple example of using the setItem method to store data:
If you run this code on a browser console, it will store a key with the name Data and a value of Hello from localStorage on localStorage.
After running the code, if you open the Applications tab and click localStorage, you’ll be able to see the Data key.
Note that you can only store strings in localStorage. (On Firefox and Chrome, the localStorage data is stored inside a Sqlite database.) If you want to keep arrays or objects, a straightforward way is to convert the data to JSON using the JSON.stringify method.
The localStorage API uses the getItem method to retrieve data. The method takes a single argument that is the key to the data. If the data is not found, the method returns null.
The syntax of the code is shown below:
As the name suggests, the removeItem() method removes a specific key-value pair from localStorage. The syntax of the data is similar to getItem. It also takes a single parameter, the item’s key, and returns undefined if the item is not available.
You can check your Applications tab of the browser dev tools to confirm that the key is removed.
If you want to clear localStorage of a particular domain, use the clear method. It doesn’t take any parameters and removes all localStorage items for the domain.
The key method comes in handy when you want to loop through the keys of localStorage. It takes a parameter of a number. The number can be an index position of the localStorage item.
Here’s an example:
The returned value can be different if your localStorage for the domain already holds some value.
To listen to events related to localStorage with DOM, use the storage event. Putting it inside a window.addEventListener can help you perform DOM operations when invoking a storage event.
Below is a simple example of listening to storage events:
Whenever a change is made to localStorage, the code sets an inner HTML to the div with the ID app to Change Made. In this case, a new item is added to localStorage for the new window, and after writing the value to localStorage, the window is closed.
Here’s the HTML for the above code:
You can also check out the CodePen link for the above example.
LocalStorage and sessionStorage do have some similarities. For example:
However, there are several differences between the two. One is persistence: data stored in localStorage persists over sessions. Opening a new tab, visiting a new domain, or closing the browser will not clear localStorage. On the other hand, sessionStorage is cleared whenever a session ends. Opening a new tab or visiting a new domain will clear the session for a specific domain.
Another difference is that, in the case of a few browsers, localStorage doesn’t work in incognito mode but sessionStorage does. In these cases, it’s a good idea to write a wrapper for your localStorage code in order to use sessionStorage.
IndexedDB is an API for storing a large amount of structured data, including files, on the client side. The data stored using IndexedDB is also persistent and is stored until it’s explicitly cleared. IndexedDB also offers a built-in mechanism for schema versioning.
IndexedDB offers several benefits over localStorage. For instance, IndexedDB doesn’t block the DOM when used with a worker, unlike localStorage. However, localStorage is slightly faster than IndexedDB. The API of localStorage is also much easier to get started with, making it the more popular choice.
The primary reason for introducing IndexedDB was to make a better version of localStorage. So, why not use IndexedDB in all cases? If you want to store structured data on the client side, IndexedDB is the better choice, especially since localStorage isn’t built to store sensitive information. But if you’re storing a simple, small amount of key-value pair data, use localStorage.
The localStorage feature can offer benefits to your applications, including open-ended storage to persist data for as long as you need it and the ability to make your applications work offline. This form of data storage won’t be the best choice in every use case, and you might need to consider IndexedDB instead in some instances.
Meticulous is a tool for software engineers to catch visual regressions in web applications without writing or maintaining UI tests.
Inject the Meticulous snippet onto production or staging and dev environments. This snippet records user sessions by collecting clickstream and network data. When you post a pull request, Meticulous selects a subset of recorded sessions which are relevant and simulates these against the frontend of your application. Meticulous takes screenshots at key points and detects any visual differences. It posts those diffs in a comment for you to inspect in a few seconds. Meticulous automatically updates the baseline images after you merge your PR. This eliminates the setup and maintenance burden of UI testing.
Meticulous isolates the frontend code by mocking out all network calls, using the previously recorded network responses. This means Meticulous never causes side effects and you don’t need a staging environment.
Learn more here.
Meticulous is a tool for software engineers to catch visual regressions in web applications without writing or maintaining UI tests. Meticulous isolates the frontend code by mocking out all network calls, using the previously recorded network responses. This means Meticulous never causes side effects and you don’t need a staging environment.