js-cookie vs localforage vs store2 vs idb-keyval vs redux-persist vs store
Web Storage Libraries Comparison
Search packages..
1 Year
js-cookielocalforagestore2idb-keyvalredux-persiststoreSimilar Packages:
What's Web Storage Libraries?

These libraries provide various methods for storing data in the browser, allowing developers to manage state and persist data across sessions. They each offer unique features and use cases, catering to different storage needs, from simple key-value pairs to complex data structures, and from session management to offline capabilities.

Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
js-cookie11,333,37022,16326.2 kB42 years agoMIT
localforage4,349,57425,207-2474 years agoApache-2.0
store23,575,5801,92589.4 kB32 months agoMIT
idb-keyval1,263,8222,85653.8 kB232 years agoApache-2.0
redux-persist1,109,19412,991-5945 years agoMIT
store266,58814,025-998 years agoMIT
Feature Comparison: js-cookie vs localforage vs store2 vs idb-keyval vs redux-persist vs store

Storage Mechanism

  • js-cookie:

    js-cookie operates on cookies, which are small pieces of data stored in the user's browser. It provides a simple API for creating, reading, and deleting cookies, with support for expiration dates and path options.

  • localforage:

    localforage abstracts multiple storage mechanisms, including IndexedDB, WebSQL, and localStorage, allowing developers to use a unified API while leveraging the best available storage option for the browser.

  • store2:

    store2 also uses localStorage but adds features like namespaces, allowing for better organization of stored data and preventing key collisions.

  • idb-keyval:

    idb-keyval uses IndexedDB, a low-level API for client-side storage of significant amounts of structured data, including files/blobs. It provides a simple promise-based API for CRUD operations, making it easy to use.

  • redux-persist:

    redux-persist integrates with Redux to persist the Redux store in storage (like localStorage or AsyncStorage). It serializes the state and rehydrates it on application startup, ensuring state continuity across sessions.

  • store:

    store uses localStorage as its primary storage mechanism, providing a simple key-value store interface for storing and retrieving data in the browser.

Data Size Limitations

  • js-cookie:

    Cookies are limited to about 4KB in size, making them unsuitable for storing large amounts of data. They are best for small pieces of information like session tokens or user preferences.

  • localforage:

    localforage can store larger amounts of data, leveraging IndexedDB or WebSQL, which can handle several megabytes, making it suitable for applications that require significant data storage.

  • store2:

    store2 inherits the same limitations as store, being based on localStorage, but provides better organization for stored data.

  • idb-keyval:

    IndexedDB has a much larger storage limit compared to cookies and localStorage, allowing for the storage of large amounts of structured data, typically several megabytes depending on the browser.

  • redux-persist:

    The data size limit for redux-persist depends on the storage engine used (like localStorage), which typically allows for about 5MB. It is designed for persisting application state rather than large datasets.

  • store:

    store is limited by localStorage, which typically allows for about 5MB of data. It is suitable for small to moderate amounts of data.

Asynchronous Support

  • js-cookie:

    js-cookie operates synchronously, meaning that cookie operations are performed immediately without any asynchronous handling. This is suitable for quick read/write operations but can be limiting for larger data handling.

  • localforage:

    localforage provides a promise-based API, allowing for asynchronous data access, which is essential for maintaining performance when dealing with larger datasets or complex operations.

  • store2:

    store2 also operates synchronously, similar to store, providing immediate access to localStorage data.

  • idb-keyval:

    idb-keyval supports asynchronous operations through promises, making it easy to handle data storage without blocking the main thread, which is crucial for performance in web applications.

  • redux-persist:

    redux-persist synchronously updates the Redux store but can be configured to use asynchronous storage engines, allowing for flexibility in how state is persisted and retrieved.

  • store:

    store operates synchronously, providing immediate access to stored data. This is suitable for simple use cases but may block the main thread for larger operations.

Ease of Use

  • js-cookie:

    js-cookie has a very straightforward API for cookie management, making it easy to create, read, and delete cookies without any additional overhead or complexity.

  • localforage:

    localforage offers a simple API that resembles localStorage but with added asynchronous capabilities, making it easy to switch from localStorage to a more powerful storage solution without significant code changes.

  • store2:

    store2 builds on the simplicity of store while adding features like namespaces, making it slightly more complex but still user-friendly for organizing stored data.

  • idb-keyval:

    idb-keyval is designed to be simple and intuitive, providing a minimalistic API that abstracts the complexity of IndexedDB, making it easy for developers to implement without deep knowledge of the underlying technology.

  • redux-persist:

    redux-persist integrates seamlessly with Redux, providing a familiar pattern for Redux developers. Its configuration options are straightforward, allowing for quick setup and customization of state persistence.

  • store:

    store is designed for simplicity, providing a clean and easy-to-use API for basic key-value storage, making it suitable for developers looking for minimal setup.

Use Cases

  • js-cookie:

    js-cookie is best suited for managing user sessions, preferences, and tracking information, where small amounts of data need to be stored and accessed quickly.

  • localforage:

    localforage is perfect for applications that need offline capabilities and require storing larger amounts of data, such as progressive web apps (PWAs) or applications with extensive user-generated content.

  • store2:

    store2 is ideal for applications that need a lightweight key-value store with better organization features, making it suitable for more structured data management.

  • idb-keyval:

    idb-keyval is ideal for applications that require storing complex data structures or large datasets, such as offline applications or data-heavy web apps that need efficient storage solutions.

  • redux-persist:

    redux-persist is tailored for applications using Redux that need to maintain user state and preferences across sessions, ensuring a seamless user experience during navigation and refreshes.

  • store:

    store is suitable for simple applications that require basic data persistence, such as saving user settings or small pieces of information without complex requirements.

How to Choose: js-cookie vs localforage vs store2 vs idb-keyval vs redux-persist vs store
  • js-cookie:

    Select js-cookie for straightforward cookie management. It is best suited for applications that need to handle cookies for session management or tracking user preferences without the complexity of other storage solutions.

  • localforage:

    Opt for localforage if you need a versatile solution that supports multiple storage backends (IndexedDB, WebSQL, and localStorage) and offers a simple API for asynchronous data access. It is great for applications that require offline capabilities and larger data storage.

  • store2:

    Select store2 if you need a more feature-rich version of store that includes support for namespaces and better data management. It is ideal for applications that require organization of stored data into different categories.

  • idb-keyval:

    Choose idb-keyval if you need a simple and lightweight way to interact with IndexedDB using a key-value store. It is ideal for projects that require asynchronous storage without the overhead of a full-fledged library.

  • redux-persist:

    Use redux-persist if you are working with Redux for state management and want to persist your Redux store across sessions. It is particularly useful for applications that need to maintain user state and preferences even after a page refresh.

  • store:

    Choose store for a lightweight and simple key-value store that works well with localStorage. It is suitable for applications that require basic data persistence without the need for advanced features or complex setups.

Similar Npm Packages to localforage

localforage is a powerful library that provides a simple API for storing data in the browser using asynchronous storage. It abstracts the complexities of different storage mechanisms, such as IndexedDB, WebSQL, and localStorage, allowing developers to store data in a more flexible and efficient manner. With localforage, you can easily store and retrieve data without worrying about the underlying implementation, making it a popular choice for web applications that require offline capabilities and persistent storage.

While localforage is a robust solution for client-side storage, there are alternatives that offer similar functionalities. Here are a couple of noteworthy options:

  • dexie is a wrapper library for IndexedDB that provides a more developer-friendly API. It simplifies the process of working with IndexedDB by offering a promise-based interface and powerful querying capabilities. Dexie allows you to define your database schema and provides features like transactions, versioning, and advanced queries, making it an excellent choice for applications that require complex data storage and retrieval operations. If you are looking for a more structured way to interact with IndexedDB, dexie is a strong alternative to localforage.

  • idb-keyval is a minimalistic library that simplifies the use of IndexedDB by providing a simple key-value store. It is built on top of the native IndexedDB API and offers a straightforward API for storing and retrieving data. idb-keyval is particularly useful for projects that require a lightweight solution for key-value storage without the overhead of a more complex library. If your application needs basic data storage capabilities with minimal setup, idb-keyval is a great option.

To see how localforage compares with dexie and idb-keyval, check out the comparison: Comparing dexie vs idb-keyval vs localforage.

Similar Npm Packages to idb-keyval

idb-keyval is a simple and lightweight library for storing key-value pairs in IndexedDB. It provides a straightforward API for interacting with IndexedDB, making it easier for developers to manage client-side storage in web applications. While idb-keyval is an excellent choice for simple key-value storage, there are other libraries that offer more advanced features or different approaches to client-side storage. Here are a few alternatives:

  • dexie is a powerful wrapper around IndexedDB that provides a more advanced and feature-rich API for managing complex data structures. It supports transactions, indexing, and querying, making it suitable for applications that require more sophisticated data management. If your project involves handling larger datasets or requires advanced querying capabilities, dexie is an excellent choice. Its promise-based API and support for TypeScript also make it a popular option among developers looking for a robust solution for client-side storage.
  • localforage is another popular library that abstracts the complexities of IndexedDB, WebSQL, and localStorage, providing a simple API for offline storage. It automatically chooses the best storage method available in the user's browser, ensuring compatibility and performance. localforage is particularly useful for applications that need to store larger amounts of data or require a consistent API across different storage backends. If you want a library that handles various storage mechanisms seamlessly, localforage is a great option.

To see how idb-keyval compares with dexie and localforage, check out the comparison: Comparing dexie vs idb-keyval vs localforage.

Similar Npm Packages to redux-persist

redux-persist is a library that allows developers to persist and rehydrate a Redux store. This means that the state of the Redux store can be saved to a storage engine (like localStorage or sessionStorage) and restored when the application is reloaded. This is particularly useful for maintaining user sessions, preferences, or any other state that should persist across page refreshes. By integrating redux-persist into your Redux setup, you can enhance the user experience by ensuring that important state is not lost.

While redux-persist is a powerful tool for state persistence, there are alternatives that can complement or provide additional functionalities. Here are a few noteworthy alternatives:

  • localforage is a library that provides a simple API for storing data in the browser. It abstracts the complexities of using different storage mechanisms (like IndexedDB, WebSQL, and localStorage) and offers a promise-based API for asynchronous storage. While localforage is not specifically tied to Redux, it can be used as a storage engine for redux-persist, allowing for more advanced storage capabilities and larger data storage limits compared to localStorage alone.

  • redux-persist-transform-encrypt is a transform for redux-persist that adds encryption capabilities to the persisted state. This is particularly useful when you need to store sensitive information and want to ensure that the data is encrypted before being saved to storage. By using this transform, you can enhance the security of your application's state persistence.

  • redux-persist-transform-filter is another transform for redux-persist that allows you to selectively persist specific parts of your Redux state. This can be useful when you want to avoid persisting large or unnecessary portions of the state, optimizing the storage and improving performance. With this transform, you can define which reducers or parts of the state should be persisted, giving you more control over the persistence process.

To explore how these packages compare, check out the following link: Comparing localforage vs redux-persist vs redux-persist-transform-encrypt vs redux-persist-transform-filter.

Similar Npm Packages to store

store is a simple and lightweight JavaScript library for managing local storage in web applications. It provides a straightforward API for storing, retrieving, and managing data in the browser's local storage, making it easy for developers to persist data across sessions. While store is a great option for local storage management, there are several alternatives that offer different features and capabilities. Here are a few notable alternatives:

  • idb-keyval is a small and simple library for using IndexedDB, which is a more powerful and flexible storage solution than local storage. It provides a promise-based API for storing and retrieving key-value pairs, making it easy to work with asynchronous data storage. If you need to store larger amounts of data or require more complex data structures, idb-keyval is an excellent choice.
  • js-cookie is a lightweight library for managing cookies in web applications. It simplifies the process of creating, reading, and deleting cookies, providing a clean and easy-to-use API. If your application requires cookie management for session handling or tracking user preferences, js-cookie is a great alternative to local storage.
  • localforage is a powerful library that provides a simple API for asynchronous storage, using IndexedDB, WebSQL, or local storage as a backend. It allows you to store various data types, including objects and arrays, and automatically chooses the best storage method available in the user's browser. If you need a more robust solution for data storage that can handle larger datasets, localforage is a strong contender.
  • redux-persist is a library designed to work with Redux, allowing you to persist your Redux store in local storage or other storage engines. It provides a way to save and rehydrate your Redux state across sessions, making it ideal for applications that use Redux for state management. If your application relies heavily on Redux and you want to persist the state, redux-persist is the way to go.
  • store2 is a lightweight library that extends the functionality of local storage, providing a more powerful API for managing data. It supports features like namespacing, expiration, and data serialization, making it a versatile option for local storage management. If you need additional features beyond what store offers, store2 is a solid alternative.

To explore how these packages compare, check out the following link: Comparing idb-keyval vs js-cookie vs localforage vs redux-persist vs store vs store2.

README for js-cookie

JavaScript Cookie CI BrowserStack JavaScript Style Guide Code Climate npm size jsDelivr Hits

A simple, lightweight JavaScript API for handling cookies

👉👉 If you're viewing this at https://github.com/js-cookie/js-cookie, you're reading the documentation for the main branch. View documentation for the latest release. 👈👈

Installation

NPM

JavaScript Cookie supports npm under the name js-cookie.

npm i js-cookie

The npm package has a module field pointing to an ES module variant of the library, mainly to provide support for ES module aware bundlers, whereas its browser field points to an UMD module for full backward compatibility.

Not all browsers support ES modules natively yet. For this reason the npm package/release provides both the ES and UMD module variant and you may want to include the ES module along with the UMD fallback to account for this:

CDN

Alternatively, include js-cookie via jsDelivr CDN.

Basic Usage

Create a cookie, valid across the entire site:

Cookies.set('name', 'value')

Create a cookie that expires 7 days from now, valid across the entire site:

Cookies.set('name', 'value', { expires: 7 })

Create an expiring cookie, valid to the path of the current page:

Cookies.set('name', 'value', { expires: 7, path: '' })

Read cookie:

Cookies.get('name') // => 'value'
Cookies.get('nothing') // => undefined

Read all visible cookies:

Cookies.get() // => { name: 'value' }

Note: It is not possible to read a particular cookie by passing one of the cookie attributes (which may or may not have been used when writing the cookie in question):

Cookies.get('foo', { domain: 'sub.example.com' }) // `domain` won't have any effect...!

The cookie with the name foo will only be available on .get() if it's visible from where the code is called; the domain and/or path attribute will not have an effect when reading.

Delete cookie:

Cookies.remove('name')

Delete a cookie valid to the path of the current page:

Cookies.set('name', 'value', { path: '' })
Cookies.remove('name') // fail!
Cookies.remove('name', { path: '' }) // removed!

IMPORTANT! When deleting a cookie and you're not relying on the default attributes, you must pass the exact same path and domain attributes that were used to set the cookie:

Cookies.remove('name', { path: '', domain: '.yourdomain.com' })

Note: Removing a nonexistent cookie neither raises any exception nor returns any value.

Namespace conflicts

If there is any danger of a conflict with the namespace Cookies, the noConflict method will allow you to define a new namespace and preserve the original one. This is especially useful when running the script on third party sites e.g. as part of a widget or SDK.

// Assign the js-cookie api to a different variable and restore the original "window.Cookies"
var Cookies2 = Cookies.noConflict()
Cookies2.set('name', 'value')

Note: The .noConflict method is not necessary when using AMD or CommonJS, thus it is not exposed in those environments.

Encoding

This project is RFC 6265 compliant. All special characters that are not allowed in the cookie-name or cookie-value are encoded with each one's UTF-8 Hex equivalent using percent-encoding.
The only character in cookie-name or cookie-value that is allowed and still encoded is the percent % character, it is escaped in order to interpret percent input as literal.
Please note that the default encoding/decoding strategy is meant to be interoperable only between cookies that are read/written by js-cookie. To override the default encoding/decoding strategy you need to use a converter.

Note: According to RFC 6265, your cookies may get deleted if they are too big or there are too many cookies in the same domain, more details here.

Cookie Attributes

Cookie attribute defaults can be set globally by creating an instance of the api via withAttributes(), or individually for each call to Cookies.set(...) by passing a plain object as the last argument. Per-call attributes override the default attributes.

expires

Define when the cookie will be removed. Value must be a Number which will be interpreted as days from time of creation or a Date instance. If omitted, the cookie becomes a session cookie.

To create a cookie that expires in less than a day, you can check the FAQ on the Wiki.

Default: Cookie is removed when the user closes the browser.

Examples:

Cookies.set('name', 'value', { expires: 365 })
Cookies.get('name') // => 'value'
Cookies.remove('name')

path

A String indicating the path where the cookie is visible.

Default: /

Examples:

Cookies.set('name', 'value', { path: '' })
Cookies.get('name') // => 'value'
Cookies.remove('name', { path: '' })

Note regarding Internet Explorer:

Due to an obscure bug in the underlying WinINET InternetGetCookie implementation, IE’s document.cookie will not return a cookie if it was set with a path attribute containing a filename.

(From Internet Explorer Cookie Internals (FAQ))

This means one cannot set a path using window.location.pathname in case such pathname contains a filename like so: /check.html (or at least, such cookie cannot be read correctly).

In fact, you should never allow untrusted input to set the cookie attributes or you might be exposed to a XSS attack.

domain

A String indicating a valid domain where the cookie should be visible. The cookie will also be visible to all subdomains.

Default: Cookie is visible only to the domain or subdomain of the page where the cookie was created, except for Internet Explorer (see below).

Examples:

Assuming a cookie that is being created on site.com:

Cookies.set('name', 'value', { domain: 'subdomain.site.com' })
Cookies.get('name') // => undefined (need to read at 'subdomain.site.com')

Note regarding Internet Explorer default behavior:

Q3: If I don’t specify a DOMAIN attribute (for) a cookie, IE sends it to all nested subdomains anyway?
A: Yes, a cookie set on example.com will be sent to sub2.sub1.example.com.
Internet Explorer differs from other browsers in this regard.

(From Internet Explorer Cookie Internals (FAQ))

This means that if you omit the domain attribute, it will be visible for a subdomain in IE.

secure

Either true or false, indicating if the cookie transmission requires a secure protocol (https).

Default: No secure protocol requirement.

Examples:

Cookies.set('name', 'value', { secure: true })
Cookies.get('name') // => 'value'
Cookies.remove('name')

sameSite

A String, allowing to control whether the browser is sending a cookie along with cross-site requests.

Default: not set.

Note that more recent browsers are making "Lax" the default value even without specifiying anything here.

Examples:

Cookies.set('name', 'value', { sameSite: 'strict' })
Cookies.get('name') // => 'value'
Cookies.remove('name')

Setting up defaults

const api = Cookies.withAttributes({ path: '/', domain: '.example.com' })

Converters

Read

Create a new instance of the api that overrides the default decoding implementation. All get methods that rely in a proper decoding to work, such as Cookies.get() and Cookies.get('name'), will run the given converter for each cookie. The returned value will be used as the cookie value.

Example from reading one of the cookies that can only be decoded using the escape function:

document.cookie = 'escaped=%u5317'
document.cookie = 'default=%E5%8C%97'
var cookies = Cookies.withConverter({
  read: function (value, name) {
    if (name === 'escaped') {
      return unescape(value)
    }
    // Fall back to default for all other cookies
    return Cookies.converter.read(value, name)
  }
})
cookies.get('escaped') // 北
cookies.get('default') // 北
cookies.get() // { escaped: '北', default: '北' }

Write

Create a new instance of the api that overrides the default encoding implementation:

Cookies.withConverter({
  write: function (value, name) {
    return value.toUpperCase()
  }
})

TypeScript declarations

npm i @types/js-cookie

Server-side integration

Check out the Servers Docs

Contributing

Check out the Contributing Guidelines

Security

For vulnerability reports, send an e-mail to js-cookie at googlegroups dot com

Releasing

Releasing should be done via the Release GitHub Actions workflow, so that published packages on npmjs.com have package provenance.

GitHub releases are created as a draft and need to be published manually! (This is so we are able to craft suitable release notes before publishing.)

Supporters

Many thanks to BrowserStack for providing unlimited browser testing free of cost.

Authors

npm-compare.com is an independent website designed to help developers choose the most suitable npm packages. We are not affiliated with npm, Inc or npmjs.com, the official website for the npm registry. Please note that npm is a registered trademark of npm, Inc. For more details, please refer to our Terms & Privacy.