How persistent is localStorage?

I'm depending heavily on localStorage for a plugin I'm writing. All the user settings are stored in it. Some settings require the user the write regex'es and they would be sad if their regex rules are gone at some point. So now I am wondering just how persistent the localStorage is.

From the specs:

> User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.

The above looks like it works just like cookies on the clientside. I.e. when the user clears all browser data (history, cookies, cache etc) the localStorage will also be truncated. Is this assumption correct?

Mozilla implements it like cookies:

> DOM Storage can be cleared via "Tools -> Clear Recent History -> Cookies" when Time range is "Everything" (via nsICookieManager::removeAll) > > https://developer.mozilla.org/en/DOM/Storage > >In DOM Storage it is not possible to specify an expiration period for any of your data. All expiration rules are left up to the user. In the case of Mozilla, most of those rules are inherited from the Cookie-related expiration rules. Because of this you can probably expect most of your DOM Storage data to last at least for a meaningful amount of time. > > http://ejohn.org/blog/dom-storage/

Chrome implements it like cache:

>LocalStorage is Not Secure Storage > >HTML5 local storage saves data unencrypted in string form in the regular browser cache. > >Persistence > >On disk until deleted by user (delete cache) or by the app > > https://developers.google.com/web-toolkit/doc/latest/DevGuideHtml5Storage

---

As for a "replacement for the Cookie", not entirely

> Cookies and local storage really serve difference purposes. Cookies are primarily for reading server-side, LocalStorage can only be read client-side. So the question is, in your app, who needs this data — the client or the server?

Basically, you should not heavily depend on Local Storage.

Local Storage, along with Session Storage, aims to be a replacement of the cookies, defining a more consistent API. There are a few differences from the cookies:

• While the cookies are accessible from both client and server side, Web Storage, in general, and Local Storage, in particular, are accessible only from client side.
• Enhanced capacity (official for cookies is 4 KB) to more than 5MB per domain (Firefox, Google Chrome, and Opera and 10MB in IE).

So yes, your assumption is correct.

One thing to note about using local storage. It is very browser specific. If you store data with firefox it won't be available in chrome or ie etc. Also as far as clearing cookies and sessions, I've noticed it is also browser specific as to whether or not the local storage is cleared. I'd look into the details a lot if you're really planning on relying on local storage for an app.

Local Storage is designed to be a dependable, persistent store of data on a client. It is not designed as a "better cookie": that function is designed to be met by Session Storage.

From the Dec 2011 Web Storage Spec Candidate Recommendation,

> (Local Storage) is designed for storage that spans multiple windows, > and lasts beyond the current session. In particular, Web applications > may wish to store megabytes of user data, such as entire > user-authored documents or a user's mailbox, on the client side for > performance reasons.

As client-side data - it is as persistent as any client side data, within the size limits that the browser implements. Users can delete it at any time, open it up in a text editor and edit etc. - just like ANY client side data.

If you're using localStorage for a iOS app, be very careful. THe latest version of iOS (5.1 off the top of my head) has moved localstorage and localdb data to a part of the cache that is regularly cleared, i.e. not at all persistent. I can't tell yet if this is a bug or a policy change.