107

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?

hippietrail
  • 13,703
  • 15
  • 87
  • 133
PeeHaa
  • 66,697
  • 53
  • 182
  • 254
  • 1
    Considering that browsers get to decide what constitutes a "security reason", in an ideal world you wouldn't assume that it will last very long. However, it's probably safe to assume that it persists until a user explicitly flushes it. – Corbin Mar 30 '12 at 18:15
  • 1
    Just one warning when using localStorage: It does not seem to work reliably in Firefox 39, 38 and 37 (we did not check anything older). On about 1% of our user's machines, the localStorage gets lost sometimes in the middle of browsing our site, while the session-cookie is preserved. Seems like a bug to me. – Andreas Aug 07 '15 at 10:04
  • 1
    @PeeHaa, It doesn't merely *work* like cookies, but are **legally defined as "cookies"** too. In fact, storage info is shown right alongside other cookies in the url `chrome:settings/cookies` – Pacerier Jan 31 '17 at 17:46

5 Answers5

73

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?

Community
  • 1
  • 1
Joseph
  • 107,072
  • 27
  • 170
  • 214
  • 1
    I think this [MDN link](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria) explained more clear. – Bo Lu Jun 05 '19 at 23:26
17

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.

Daniel Ribeiro
  • 9,621
  • 9
  • 42
  • 75
  • 1
    +1 -- this is why I'd use local storage as a cache and backup user data on the server. (Of course, that assumes there's a login mechanism in place.) – josh3736 Mar 30 '12 at 18:23
  • 2
    `Basically, you should not heavily depend on Local Storage.` ... Absolutely !! – Tenali Raman Oct 23 '15 at 13:44
7

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.

Luke
  • 1,893
  • 1
  • 16
  • 25
5

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.

Michael Mullany
  • 25,795
  • 5
  • 68
  • 94
  • 1
    Perhaps this has changed since your original post 8 years ago, but Local Storage can very much be used as a replacement for cookies (where client-side only access is needed). Session Storage cannot. Session Storage is deleted as soon as the browser is closed. – Brad Apr 25 '20 at 16:49
3

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.

Wytze
  • 7,494
  • 8
  • 46
  • 61