HTML5 Local Storage Revisited

Local storage is part of the HTML5 Web Storage API and it allows you to store data in the browser. Unlike cookies, data stored using local storage isn’t sent back to the server. All data stays on the client, and you can currently store from 2MB to 10MB. This limit is tied to the specific browser, protocol (HTTP or HTTPS), port, and top level domain in use.

In this article, we’ll discuss how to use this API to improve the performance of a website. I’ll assume that you know what local storage is and the methods exposed, but if you need a refresher I suggest you read the article An Overview of the Web Storage API by Colin Ihrig.

Available disk space

Before we start the discussion of local storage, I want to give you an overview of the available disk space in major mobile and desktop browsers. The following tables are based on the article “Working with quota on mobile browsers”.

Mobile browsers:

Browser Chrome Android Browser Firefox iOS Safari
Version 40 4.3 34 6-8
Space available 10MB 2MB 10MB 5MB

Desktop browsers:

Browser Chrome Opera Firefox Safari Internet Explorer
Version 40 27 34 6-8 9-11
Space available 10MB 10MB 10MB 5MB 10MB

Native cache vs local storage

When using local storage, your data will stay on the client and persist across sessions and device restarts. As I mentioned in the introduction, the limit of the local storage API is tied to the specific browser (as shown in the previous tables), protocol, port, and top level domain in use. By contrast, the space available on the browser’s native cache is shared across websites, and it’s much smaller on mobile devices. It gets flushed frequently, sometimes even within the same visit. Mobile devices have an additional issue: they’re less powerful than desktop devices, so achieving good performance is a must.

There has been a lot of discussion about local storage performance. For example, Christian Heilmann, formerly with Mozilla, wrote “There is no simple solution for local storage”. Local storage can have a performance hit if not used carefully. The first thing you need to take into account is that it’s a synchronous API, therefore it blocks the main UI thread. Local storage writes and reads data from the hard drive, which can be a much more expensive operation than reading from memory. In order to give you access to the data, local storage needs to read the data from the disk, and that’s where the performance hit occurs. This performance hit is not a major issue with small amounts of data, but it can be noticeable using the full storage limit.

As a good practice you should try to perform as few reads as possible. Also, because we are dealing with a synchronous API, you should try to read data from local storage only after the window.onload event has fired, to avoid blocking the UI thread.

Things have changed

But things are getting better. An article published by Peter McLachlan of Mobify explained that local storage can be 5x faster than native cache on mobile devices.

Smartphone local storage outperforms browser cache

In the appendix of the same article you can see the evolution of the performance of local storage on mobile browsers and how much it’s improved. You can also see that local storage has always been faster than native cache.

Who’s using local storage?

There are some recent cases of websites using local storage to cache assets, such as The Guardian who are using local storage for critical path CSS. You can view this presentation given at Velocity conference 2014 to understand more about how they are able to do this.

Also Smashing Magazine recently started caching web fonts in local storage. In this article about some performance improvements implemented recently on their website, they report deferring web fonts and caching them in local storage among the changes that led to the most effective improvements.

A note on Private Browsing

As reported on, under the tab known issues, when running in private or incognito mode, Safari, iOS Safari, and Android browsers don’t support setting items in local storage.

Other browsers such as Chrome and Firefox allow you to store data in local storage under private mode, but the data is purged when you exit private mode. This is due to privacy issues, as someone might use the persistent data to learn about the user’s actions when in private mode.

This issue may break your application’s behavior if a value set under a previous session is expected to be there at a subsequent visit. So, in order to use local storage safely, it’s a good practice not only to test for support, but also to test for the capacity to get and set items.

For more info on local storage behavior under private mode and on how to check local storage content in different browsers, you can use the article “Don’t Forget To Check Private Browsing Mode When Testing” as a reference.


Maybe it’s time that we start revisiting local storage and its potential usage, especially on mobile devices where we can use it to avoid latency bottlenecks. We can start thinking about new ways to cache our assets, and then serve them instantly to our users. We’ve seen there are already some successful implementations of local storage usage in unconventional ways.


Thank you for this article. I have not used localStorage in a production environment - I've only played around with it a bit, and I do love it.

However, I did learn something about localStorage (and, by default, sessionStorage, too) that is something to be aware of.

If you clear your browser cookies, local/sessionStorage is not affected. HOWEVER, if you clear the browser history, all of local/sessionStorage is cleared.

So, if a user clears their cache and cookies on every exit, you're site/app is safe with localStorage.

But if the user clears browser history on exit, localStorage is useless. Or, at least, it won't be there the next time the user visits.




Yes that's true local storage gets deleted when deleting browser history, i believe it might be due to privacy issues


Local Storage is a neat concept but since it is a String:String key:value pair store you'll need to deal with conversions when dealing with numbers, dates, maps, arrays, etc.

The 5MB Safari limit also makes large scale apps just simply not an option. However the simplicity of the API is appreciated and thus Mozilla's localForage framework is a great alternative with a very similar (but async) API that sits on top of the more capable IndexedDB APIs.

Hopefully in time all browsers will support the Quota API and or increase the localStorage to a realistic level! wink


The good news for this particular issue, is that JSON is an excellent format in which to store such data.


I know that the user (if they know how) can change the limit in FF and IE; does Safari have the same ability?




Local storage is also a handy way of transferring data between windows or tabs, if that's needed.

You can test the storage limit and user settings with exception handling. If referring to window.localStorage throws an error, then user security policy has disabled it. If setting a value throws an error, then you've exceeded the data limit. The safest approach is to use exception handling every time you use local storage.

    var storage = window.localStorage;
    //storage is disabled by user settings

    storage.key = value;
    //set would exceed storage quota

JSON is very useful, but JSON itself is expensive to parse -- if the data is complex and hierarchical, then yeah, JSON is a good choice. But if it's just a bunch of simple values, then it's better to use a simple delimiter (like comma) and parse that manually.

But in that browser cache vs local storage graph, are the colour codes the wrong way round, or am I missing something? The written conclusion is that local storage is faster, but the graph shows that browser cache is faster in every case.


It's also worth noting potential race conditions with local storage:

storage.key = value;

console.log(storage.key);    //may be undefined

In practise, I've only ever encountered this problem once, with immediate set and read like the example above. I solved it with a 1ms timeout, but even that was probably way more time than it really needed.


Probably the best way to handle it. But I'm currently using an alternative approach.

var strge = (!!window.localStorage) ? "localStorage" : "cookie" ;
var storage = (strge === "localStorage") ? window.localStorage : false ;


if(!!storage) { do localStorage stuff; } else { do cookie stuff; }




Interesting. But if the data you're using is small enough (and doesn't matter if it's sent in network requests), then why not just use cookies for all?


Security. Cookies, even if set for only a specific domain, can be hacked (if a hacker or script-kiddie know what they're doing.) local/sessionStorage is more difficult to intercept (not impossible, just really, really, really difficult.)

Although, I understand that local/sessionStorage can be set by the developer to be available to specific domains.




That's kind of my point though -- storage and cookies have different features. So what possible use is a function that falls back to cookies if storage isn't available?


Y'know what.. I don't care, anymore. You're the second person in one day to give a semi-snarky response to my thoughts.

Don't agree with it. I don't care.

I really shouldn't be using company time to do non-work-related things, anyway.



Mate, I wasn't remotely snarky. I'm simply discussing your approach with you.

The lady doth protest too much, methinks


Perhaps listing the differences would be useful. The main two I can think of are:

  • The difference in the amount of space available.
  • That cookies get sent to the server and local/session storage doesn't.

Yeah, those two differences are the significant ones.

Cookies only give you 4K, which is obviously a lot less than 2-10MB!

Cookies can be written and read by the server, but storage is client-side only (although Node.js has a storage extension with the same syntax, and that data can be passed across the network).

The network difference also gives rise to a minor security benefit, in that local storage data can't be intercepted by man in the middle attacks. But local storage isn't secure storage, and it's just as easy for users to modify their own storage data, eg. to modify stored credentials in order to assume another identity (if they know the other identity's credentials). And of course it's just as vulnerable to XSS attacks as any other data.

Oh, and storage has an event which fires in response to storage changes. This event is the mechanism through which you can communicate between windows and tabs (because it fires in all instances, not just the active one; it would also make it possible to implement cross-window drag and drop with keyboard support, but that's another article!).

I think that's it, can't think of anything else -- unless you count browser support (obviously much wider for cookies); or the fact that local storage is way cleaner and easier to use smile


"local/sessionStorage is more difficult to intercept (not impossible, just really, really, really difficult.)"

If you mean "intercept" as in something between the client and server, then it is more then difficult, it is impossible as LS values aren't sent to the server. If you mean "intercept" as in see/modify, then you are very wrong. Modifying LS values is as simple as opening up dev tools. You get a nice view of all the data and you can modify them easily enough. To be clear, that doesn't make the feature bad, I love LS, but it is trivial for users to see how you use it.


Ray! Glad to see you, again. How's the new gig?

Yeah, user modification - for those who even know A) it's there, and B) how to get to it - is mucho easy. As brothercake points out, that can be used to assume someone else's online identity for a particular site/app. But the user would have to know what ID to assume. I think encrypting the data would be a deterrent, but only for all but the most pedantic and determined.




That's the bottom line isn't it -- obfuscation isn't security. It doesn't matter how difficult it is or how determined or knowledgeable someone would have to be; if the data is exposed, then it's not secure.

Even if you encrypted it, well then you'd have to decrypt it again -- using client-side code ... which the user can see, and use themselves!

Local storage is useful for a whole host of things, but secure information is not one of those things smile