Is Local Storage Persistent?

As web applications become more complex, the desire to store user-specific information across different web pages increase. Users tend to interact with many different functionalities of a website. Their previous actions often dictate what they should see next. In other words, the user expects a personalized experience.

In order to provide this type of specialized experience, small snippets of data are needed to be stored within the confines of their browser. Thankfully, the browser allows us to accomplish this in a variety of ways. Storing these small pieces of data locally on the client-side reduces the amount of data we have to send to the server.

In order to be effective, this data must not be critical for the database/server to know about. But rather allows the website to render logic based on what the user should be seeing.

To accomplish this, JavaScript developers often useĀ local storageĀ (a storage API on the window object). Essentially, local storage is a browser API that can we interact with in order to store small segments of data.

This seems like a great method, but an important consideration when trying to store non-essential data is its ability for it to remain stored across multiple web pages.

So, with this in mind, is local storage persistent?

Similar to cookies, local storage is designed to a dependable, persistent browser data storage on the clientside.Ā However, it is not permanent. The data stored with it is specific to the user and their browser. While other web apps are unable to read from it.

In contrast to cookies, local storage items are not sent along in network requests, which reduces overall network traffic. Additionally, cookies generally have a maximum size of around 4kb, which limits a web app that wants offload some storage about the user to the browser.

LocalStorage can be thought of as a long term cache that will remain available within a particular browser. It is completely accessible by the user, they are free to clear it or modify it.

There are also browser-specific ways of dealing with how persistent local storage is. How long the local storage lasts is dictated by the rules set out by the individual browser. Local storage remains persistent in different tabs/windows when the application is opened from the same domain.

Thankfully, the use of local storage is widely supportedĀ between all browsers. And as mentioned, there are different rules regarding how the storage is actually cleared.

Here is a breakdown of the different user interactions that can occur to clear local storage across multiple browsers:

ChromeFirefoxInternet ExplorerSafari 
Deleted when browsing data is clearedDeleted when user clears recent historyDeleted when navigating to Tools--Internet OptionsDeleted when Safari is clicked
Deleted when cookies and other sites data is clearedDeleted when cookies are clearedDeleted when navigating to General tabDeleted when navigating to Preferences and manually clearing
Deleted when history is deleted from "beginning of time"Deleted when time range is set to everythingDeleted when "Cookies and website data" is toggledDeleted using the privacy tab
Can be deleted manually site by site using :
Will not persist if "Preserve Favorites website data" is uncheckedDeleted when clicking "Remove all website data"

Some key features of local storage also include:

  • To share data across multiple instances of the same browser.
    • For example, Chrome local storage will persist across multiple tabs and instances but will not share this data with Internet Explorer
  • A large initial local storage (5MB per domain)
  • A simple way of accessing data, utilizing key-value stringsĀ 

When should I use it?

So we have already analyzed how the persistence of local storage works. It’s evident that it is not permanent, but it still serves a very practical purpose. It’s typically used to store information about the user’s state, often dictating whether or not a UI element is shown.

Remember, LocalStorage is not secure storage. It is unencrypted and in a string format. Any JavaScript file in the browser can access it, including Chrome extensions and injected scripts.

Hence, there are recommended characteristics of data that should be used with local storage.

  • The data should not sensitive
    • It shouldn’t contain valuable information about the user such as payment info or passwords
  • The data should not be crucial for the server to know about
    • Generally, arbitrary actions that the user has taken in the UI is considered non-vital for the server to know about so therefore suitable for local storage
    • Local user preferences don’t have to be sent over to the server and thus are a viable candidate for local storage
  • The size of the data stored must be small
    • Storing small images and videos should be avoidedĀ 
    • Even with a 5mb amount allocated to local storage, that is quite a lot for string data.Ā If all that data is required, local storage might not be the best option and an alternative method of storage might be better

There are certainly more considerations but these general rules of thumb enable local storage to be as effective as possible.

With this in mind, let’s look at some common situations where local storage is used.

Showing Modals

A great example of demonstrating the practicalities of local storage is the toggling of a modal. Websites often use modals for lead collections where they entice their users to give them their details in exchange for something of value.

localStorage.setItem('user', 'modalShown');
const getUserModalStatus = localStorage.getItem('user');
const modalAlreadyShown = getUserModalStatusĀ === "modalShown"
if (modalAlreadyShown) {

else {

It’s also a situation where an interfering modal popup can cause a user to bounce off the webpage completely. This is even more likely to happen if the user sees the same modal popup in one session.Ā 

This is undoubtedly infuriating for the user and is often the cause of a user leaving the page completely. In order to combat this, local storage can be used to take note of when the user has already seen the modal.

Even if the user navigates away from the website and comes back, they won’t be pestered by an intrusive popup. By the time local storage is cleared, if modal appears again, it won’t seem as jarring.

Persisting forms

When entering form data, one of the most frustrating experiences for users is losing all the information that they have just entered. There are many ways this can happen including:

  • An unexpected crash by the browser
  • An accidental refresh of the page
  • Navigating to the previous page

In situations where non-secure form data is being entered, local storage can provide a great method of persisting the user’s form state. Most notably, sending a long message in a text field to another user is definitely something that would be frustrating to lose.

As local storage is essentially just string data, saving long messages using a framework like React and its lifecycle method is relatively straightforward.

Simply set the storage:

componentWillUpdate(nextProps, nextState) {
  localStorage.setItem('user', JSON.stringify(nextState));

And when the component mounts again:

componentDidMount() {
  const userFormData = JSON.parse(localStorage.getItem('user'));

  if (localStorage.getItem('user')) {

else {
          name: '',
          email: '',

Recent Searches

Another frequently encountered situation when using a website’s search functionality is the ability to record recent searches. For a user without a registered account, this was problematic. Cookies were sometimes used to accomplish this, however, with a 4kb maximum capacity for storage, other more important data storage opportunities were often compromised as a result.

Instead, leveraging local storage to collect recent searches by the user is a much more preferred solution in the modern browser. Because recent searches are not necessarily data-sensitive (depending on the website) and they aren’t essential to be stored in the server, its great solution for the issue.

How can I see local storage?

Local storage creates ample opportunity for the client to take some pressure off a server. In situations where we want to debug or even clear local storage its important to know where to look.

Similar to cookies, LocalStorage can be inspected using browser developer tools. They allow a user to remove any stored data and see what exact value is actually being stored.

In Chrome go:

  1. Press f12
  2. Navigate to the Application section of the toolbar
  3. Click on Local Storage

Here is an example of a site that has a range of properties relating to the browsing experience of a specific user:

This small amount of data can be very important for the logic of a web application. It’s even more beneficial that it doesn’t have to be requested from the server every time.

From this view, we also have the ability to clear and modify all data inside local storage.


Local storage has been a great alternative for storing useful information in the browser. It doesn’t outright replace the functionality of cookies but rather assists in storing user preferences and general non-vital app state.

Its ability to recover a user’s data if the user exits the webpage is perhaps its most helpful purpose. However, it also takes some load off our network requests to the server which from a developer’s standpoint is incredibly beneficial to the overall health of a web app and its users.

Proudly published with Gatsby