awesome-web-storage alternatives and similar libraries
Based on the "Storage" category.
Alternatively, view awesome-web-storage alternatives based on common mentions on social networks and blogs.
9.0 0.0 L2 awesome-web-storage VS localForage💾 Offline storage, improved. Wraps IndexedDB, WebSQL, or localStorage using a simple but powerful API.
🍉 Reactive & asynchronous database for powerful React and React Native apps ⚡️
5.2 0.0 L5 awesome-web-storage VS cross-storageCross domain local storage, with permissions
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of awesome-web-storage or a related project?
Everything you need to know about Client-side Storage.
Table of Contents
- Browser Support
- [Comparison Table](comparison-table)
What is Web Storage
Web storage, sometimes known as DOM storage (Document Object Model storage), provides web application software methods and protocols used for storing data in a web browser.
Modern websites and web applications these days are becoming smarter than before and to achieve such smartness, the data storage system plays a very crucial role. Be it storing visitors' data & settings or any kind of information, web-storage is a breakthrough in the history of web applications. It offers a very basic need of storing persistent data in the browser itself which has literally spurred up its application from game-changing novelty to must-have features.
Usually, this kind of data doesn't need a well-organized backend database. The purpose of the data varies as per the website/webapp requirements. Different pages of the same website need to share data among themselves to behave alike and perfectly. This sharing of data among windows/tabs is very common these days and most of the sites or web apps use it for various jobs like User Authentication, Personalization (showing different views to a new visitor and on subsequent visits), Tracking user behavior, etc.
Before HTML5, storing application level data was possible only using cookies. Cookies can store up to 4KB of data, including the bytes consumed by the cookie name. This domain-specific data is sent along with every browser request. With the advent of HTML5, it's much easier now to store structured data on the client-side securely and faster than ever. HTML5 introduced the concept of Web Storage. Web storage can be viewed simplistically as an improvement on cookies, providing much greater storage capacity. HTML5 introduces two such web storage mechanisms: LocalStorage and SessionStorage. There are so many limitations in using cookies which can now be overcome using web storage.
There's no term as "Perfectly Secured Persistent Storage" available in the browsers as any type of storage system( persistent or non-persistent) can be manually tweaked by the end-user(assuming she knows a bit of geeky stuff :P).
Web Storage concepts and usage
The two mechanisms within Web Storage are as follows:
sessionStoragemaintains a separate storage area for each given origin that's available for the duration of the page session (as long as the browser is open, including page reloads and restores).
localStoragedoes the same thing, but persists even when the browser is closed and reopened.
Web Storage interfaces
Allows you to set, retrieve and remove data for a specific domain and storage type (session or local.)
The Web Storage API extends the
Windowobject with two new properties —
Window.localStorage— which provide access to the current domain's session and local Storage objects respectively, and a
Window.onstorageevent handler that fires when a storage area changes (e.g. a new item is stored.)
The storage event is fired on a document's Window object when a storage area changes.
|IE / Edge||Firefox||Chrome||Safari||Opera|
Different Storage APIs
Following are various storage techniques which HTML5 storage provides. Each technique has its own pros and cons.
HTTP cookie(web cookie, browser cookie) is a small piece of data that a server sends to the user's web browser. The browser may store it and send it back with the next request to the same server. Typically, it's used to tell if two requests came from the same browser — keeping a user logged-in, for example. It remembers stateful information for the stateless HTTP protocol.
- Session Management - Easy to use with logins, shopping carts, game scores, or anything else the server should remember
The 4K limit is for the entire cookie, including name, value, expiry date etc. To support most browsers, keep the name under 4000 bytes, and the overall cookie size under 4093 bytes.
Typically, the following are allowed:
- 300 cookies in total
- 4096 bytes per cookie
- 20 cookies per domain
- 81920 bytes per domain(Given 20 cookies of max size 4096 = 81920 bytes.)
Reading all cookies accessible from the domain
var allCookies = document.cookie;
Writing a new cookie on a domain
document.cookie = newCookie;
As mentioned in the mdn docs, any of the following cookie attribute values can optionally follow the key-value pair, specifying the cookie to set/update, and preceded by a semi-colon separator:
* `;path=path` - (e.g., '/', '/mydir') If not specified, defaults to the current path of the current document location. * `;domain=domain` - (e.g., 'example.com' or 'subdomain.example.com'). * `;max-age=max-age-in-seconds` - (e.g., 60\*60\*24\*365 or 31536000 for a year) * `;expires=date-in-GMTString-format` - If not specified it will expire at the end of a session. * `;secure` - Cookie to only be transmitted over secure protocol as `https`. Before `Chrome 52`, this flag could appear with cookies from `http` domains.
Resources - more on cookies
- Browser Extensions
- EditThisCookie(For Chrome) - Open source Chrome extension which does it all!
- Cookies(For Chrome) - A powerful and easy-to-use Cookie Editor.
- Cookie Inspector(For Chrome) - Edit and create cookies right in the Developer Tools.
- EditThisCookie(For Firefox)
- Cookies Manager+ - To view, edit and create new cookies.
- Vanilla Cookie Manager(For Chrome) - A Cookie Whitelist Manager that helps protect your privacy. Automatically removes unwanted cookies.
localStorageproperty allows you to access a
Storageobject for the
Document's origin; the stored data is saved across browser sessions.
localStorageis similar to
sessionStorage, except that while data stored in
localStoragehas no expiration time, data stored in
sessionStoragegets cleared when the page session ends — that is, when the page is closed.
If you look at the Mozilla source code it can be seen that 5120KB (5MB which equals 2.5 Million characters on Chrome) is the default storage size for an entire domain. This gives you considerably more space to work with than a typical 4KB cookie.
The data stored in localStorage persists until explicitly deleted. Changes made are saved and available for all current and future visits to the site.
Structured data can be stored but it has to be stringified before storing.
Simple API to save, update, and delete data.
It works on same-origin policy. So, data stored will only be available on the same origin.
It stores everything as a string.
setItem Description method localStorage.setItem(key, value) params key(String/Number),value(Number/String),though it accepts other types, the value is always stored as a string, so, stringifying data before storing is preferred and the best way to avoid errors while reading description adds the key to the storage with the value, or update the key's value if it already exists. example localStorage.setItem('test', document.getElementById('js-btn').value);
getItem Description method localStorage.getItem(key) params key(String/Number) description returns the value of the key passed. example localStorage.getItem('test')
removeItem Description method localStorage.removeItem(key) params key(String/Number) description removes the key from the storage. example localStorage.removeItem('test')
clear Description method localStorage.clear() params None description empties all the keys out of the storage. example localStorage.clear()
key Description method localStorage.key(n) params n(a Number) description returns the name of the nth key in the storage. example localStorage.key(0)
length Description property localStorage.length description returns the length of all the keys example localStorage.length
Resources - more on localStorage
- angular-local-storage - An AngularJS module that gives access to the browsers local storage with cookie fallback.
- react-native-localstorage - Local storage wrapper for both react-native and browser.
- vue-local-storage - Vue.js localStorage plugin with types support.
- localForage - Offline storage, improved. Wraps IndexedDB, WebSQL, or localStorage using a simple but powerful API.
- basket.js - A script and resource loader for caching & loading files with localStorage.
- secure-ls - Secure localStorage data with high level of encryption and data compression.
- Browser Extensions
- HTML5 Storage Manager All in One - Complete Storage Manager Extension Ever!
sessionStorageproperty allows you to access a session
Storageobject for the current origin. sessionStorage is similar to
Window.localStorage, the only difference is while data stored in localStorage has no expiration set, data stored in sessionStorage gets cleared when the page session ends. A page session lasts for as long as the browser is open and survives over page reloads and restores. Opening a page in a new tab or window will cause a new session to be initiated, which differs from how session cookies work.
Data can only be saved per window (or tab in browsers like Chrome and Firefox). Data saved is available for the current page, as well as for the future visits to the site on the same window. Once the window is closed, the storage is deleted.
The data is available only inside the window/tab in which it was set.
The data is non-persistent i.e. it will be lost once the window/tab is closed.
localStorage, it also works on same-origin policy. So, data stored on one protocol/domain/port will not be available for different protocol/domain/port.
setItem Description method sessionStorage.setItem(key, value) params key(String/Number),value(Number/String),though it accepts other types, the value is always stored as a string, so, stringifying data before storing is preferred and the best way to avoid errors while reading description adds the key to the storage with the value, or update the key's value if it already exists. example sessionStorage.setItem('test', document.getElementById('js-btn').value);
getItem Description method sessionStorage.getItem(key) params key(String/Number) description returns the value of the key passed. example sessionStorage.getItem('test')
removeItem Description method sessionStorage.removeItem(key) params key(String/Number) description removes the key from the storage. example sessionStorage.removeItem('test')
clear Description method sessionStorage.clear() params None description empties all the keys out of the storage. example sessionStorage.clear()
key Description method sessionStorage.key(n) params n(a Number) description returns the name of the nth key in the storage. example sessionStorage.key(0)
length Description property sessionStorage.length description returns the length of all the keys example sessionStorage.length
Resources - more on sessionStorage
- Browser Extensions
- HTML5 Storage Manager All in One - Complete Storage Manager Extension Ever!
|Size limit||Max 4kb (~2K chars)||Max 5mb (~2M chars)||Max 5mb (~2M chars)|
|Payload||In every HTTP req||Nothing||Nothing|
|Browser Sipport||All||IE8+, Edge12+, Firefox3.5+, Safari4+, Opera11.5+||IE8+, Edge12+, Firefox3.5+, Safari4+, Opera11.5+|
|Size limits info||limit||limit||limit|
Worth mentioning API for tackling cross-origin restriction
One very interesting API, PostMessage is not a web-storage technique but it's the most efficient and reliable way of communicating between
cross-originbrowser windows/tabs. Along with web-storage APIs, it overcomes the web-storage restrictions of cross-origin.
Safely enables cross-origin policy communication.
As a data point, the WebKit implementation (used by Safari and Chrome) doesn't currently enforce any limits (other than those imposed by running out of memory).
Need to open a window from the current window and only then can communicate as long as you keep the windows open.
otherWindow.postMessage(message, targetOrigin, [transfer]);
otherWindow - A reference to another window; such a reference may be obtained, for example, using the
contentWindow property of an
iframe element, the object returned by window.open, or by named or numeric index on Window.frames, if you're trying to start the communication from iframe to parent window then parent is also a valid reference
message - Data to be sent to the other window. The data is serialized using the structured clone algorithm. This means you can pass a broad variety of data objects safely to the destination window without having to serialize them yourself. 
targetOrigin - Specifies what the origin of
otherWindow must be for the event to be dispatched, either as the literal string
"*" (indicating no preference) or as a URI. If at the time the event is scheduled to be dispatched the scheme, hostname, or port of otherWindow's document does not match that provided in
targetOrigin, the event will not be dispatched; only if all three match will the event be dispatched. This mechanism provides control over where messages are sent; for example, if
postMessage() was used to transmit a password, it would be absolutely critical that this argument be a URI whose origin is the same as the intended receiver of the message containing the password, to prevent interception of the password by a malicious third party. Always provide a specific targetOrigin, not
*, if you know where the other window's document should be located. Failing to provide a specific target discloses the data you send to any interested malicious site.
transfer(Optional) - Is a sequence of Transferable objects that are transferred with the message. The ownership of these objects is given to the destination side and they are no longer usable on the sending side.
If you do not expect to receive messages from other sites, do not add any event listeners for
message events. This is a completely foolproof way to avoid security problems.
If you do expect to receive messages from other sites, always verify the sender's identity using the
origin and possibly
source properties. Any window (including, for example,
http://evil.example.com) can send a message to any other window, and you have no guarantees that an unknown sender will not send malicious messages. Having verified identity, however, you still should always verify the syntax of the received message. Otherwise, a security hole in the site you trusted to send only trusted messages could then open a cross-site scripting hole in your site.
Always specify an exact target origin, not
*, when you use postMessage to send data to other windows. A malicious site can change the location of the window without your knowledge, and therefore it can intercept the data sent using
Resources - more on postMessage:
- Browser Extensions
- postMessage debugger - This extension prints messages sent with postMessage to the console.
How to store data that works Cross-Origin too?
A combination of
postMessage and localStorage / sessionStorage
Using postMessage to communicate between multiple tabs and at the same time using localStorage/sessionStorage in all the newly opened tabs/windows to persist data being passed. Data will be persisted as long as the tabs/windows remain open in case of sessionStorage and in the case of localStorage unless the data is deleted by the system or manually flushing it using dev tools. So, even if the opener tab/window gets closed, the opened tabs/windows will have the entire data even after getting refreshed.
- [across-tabs](https://github.com/wingify/across-tabs/) - Easy communication between cross-origin browser tabs
Please ensure your pull request adheres to the following guidelines:
- Search previous suggestions before making a new one, as yours may be a duplicate.
- Make sure the list is useful before submitting. That implies it has enough content and every item has a good succinct description.
- Make an individual pull request for each suggestion.
- Use title-casing (AP style).
- Use the following format:
- Link additions should be added to the bottom of the relevant category.
- New categories or improvements to the existing categorization are welcome.
- Check your spelling and grammar.
- Make sure your text editor is set to remove trailing whitespace.
- The pull request and commit should have a useful title.
- The body of your commit message should contain a link to the repository.
To the extent possible under law, Varun Malhotra has waived all copyright and related or neighboring rights to this work.
*Note that all licence references and agreements mentioned in the awesome-web-storage README section above are relevant to that project's source code only.