js-cookie vs localforage vs store2 vs idb-keyval vs redux-persist vs store
Web Storage and State Management
js-cookielocalforagestore2idb-keyvalredux-persiststoreSimilar Packages:
Web Storage and State Management

Web Storage and State Management libraries in JavaScript provide developers with tools to store data on the client side, manage application state, and persist data across sessions. These libraries leverage browser storage mechanisms like Local Storage, Session Storage, and IndexedDB to store key-value pairs, allowing for efficient data retrieval and manipulation. They help improve application performance, enable offline capabilities, and enhance user experience by retaining data between sessions. Examples include localforage, which provides a simple API for asynchronous storage across different backends, and redux-persist, which integrates with Redux to automatically persist and rehydrate application state.

Npm Package Weekly Downloads Trend
3 Years
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
js-cookie15,684,68622,75826.2 kB33 years agoMIT
localforage5,355,66125,671-2494 years agoApache-2.0
store23,224,4821,94789.4 kB3a year agoMIT
idb-keyval2,557,9423,093928 kB246 months agoApache-2.0
redux-persist1,345,16513,004-5956 years agoMIT
store415,49414,018-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 works with cookies, which are small pieces of data stored in the browser and sent to the server with each HTTP request. Cookies are limited in size (typically 4KB) and can have expiration dates, making them suitable for storing small amounts of data.

  • localforage:

    localforage supports multiple storage backends, including IndexedDB, WebSQL, and LocalStorage. It automatically selects the best available storage option based on the browser, allowing for efficient storage of both small and large data sets with a promise-based API.

  • store2:

    store2 enhances the store library by adding support for namespacing, expiration, and better handling of complex data types. It also provides a unified API for Local Storage, Session Storage, and Cookies, making it easy to work with different storage methods.

  • idb-keyval:

    idb-keyval uses IndexedDB as its storage mechanism, which allows for storing large amounts of structured data asynchronously. It is designed for key-value storage and provides a simple API for interacting with IndexedDB without the complexity of its native API.

  • redux-persist:

    redux-persist is not a storage mechanism itself but integrates with existing storage solutions (like Local Storage) to persist the Redux store state. It serializes the state and saves it to the specified storage, allowing for state rehydration on page reloads.

  • store:

    store provides a unified API for working with Local Storage, Session Storage, and Cookies. It abstracts the differences between these storage mechanisms, allowing developers to store data without worrying about which method is being used.

Data Persistence

  • js-cookie:

    js-cookie provides temporary persistence for data stored in cookies. Cookies can have expiration dates set, allowing them to persist for a specified duration. However, they can also be deleted by the user or expire if not configured correctly.

  • localforage:

    localforage provides persistent storage across sessions by storing data in the browser using the best available backend (IndexedDB, WebSQL, or LocalStorage). The data remains available until explicitly deleted by the application or the user.

  • store2:

    store2 provides persistent storage similar to the store library, with added features like namespacing and expiration. The data remains available until it is deleted or the storage is cleared, making it suitable for long-term storage of key-value pairs.

  • idb-keyval:

    idb-keyval provides persistent storage, meaning that data stored using the library remains available even after the browser is closed or the page is reloaded. The data is stored in IndexedDB, which is designed for long-term storage of structured data.

  • redux-persist:

    redux-persist provides persistence for application state by saving the Redux store data to a specified storage solution (like Local Storage). The state remains available across page reloads, making it useful for maintaining user preferences and application state.

  • store:

    store provides persistent storage for key-value pairs using Local Storage, Session Storage, or Cookies. The data remains available until it is explicitly deleted or the storage is cleared by the user or the browser.

API Simplicity

  • js-cookie:

    js-cookie provides a very simple and intuitive API for managing cookies. It has clear methods for setting, getting, and deleting cookies, making it easy for developers to handle cookie operations without any hassle.

  • localforage:

    localforage features a simple, promise-based API for storing and retrieving data. It abstracts the complexity of different storage backends, allowing developers to use a consistent interface for all storage operations.

  • store2:

    store2 provides a simple and intuitive API for working with Local Storage, Session Storage, and Cookies. It enhances the store library with additional features while maintaining a user-friendly interface.

  • idb-keyval:

    idb-keyval offers a simple and minimalistic API for interacting with IndexedDB. It provides straightforward methods for setting, getting, and deleting key-value pairs, making it easy to use without needing to understand the complexities of IndexedDB.

  • redux-persist:

    redux-persist provides a simple API for integrating state persistence into a Redux application. It requires minimal configuration to set up and works seamlessly with existing Redux stores, making it easy to add persistence functionality.

  • store:

    store offers a straightforward API for storing and retrieving key-value pairs. It abstracts the differences between Local Storage, Session Storage, and Cookies, allowing developers to use a consistent interface for all storage operations.

Handling Complex Data

  • js-cookie:

    js-cookie is limited to handling simple data types (strings) since cookies store data as key-value pairs in string format. Complex data types must be serialized before being stored in cookies, and deserialized after retrieval.

  • localforage:

    localforage can handle complex data types natively, including objects, arrays, and binary data. It automatically serializes and deserializes data using the best available method, making it easy to store and retrieve complex data without additional processing.

  • store2:

    store2 can handle complex data types, including objects and arrays, and provides better support for them compared to the original store library. It automatically serializes and deserializes data, making it easier to work with complex structures without manual serialization.

  • idb-keyval:

    idb-keyval can handle complex data types, including objects and arrays, since it stores data in IndexedDB, which supports structured data. However, the data must be serialized (e.g., using JSON) before storing and deserialized when retrieving it.

  • redux-persist:

    redux-persist can handle complex data types as long as they are serializable. It serializes the entire Redux store state (including objects, arrays, and nested structures) before storing it in the specified storage solution. However, non-serializable data (e.g., functions, class instances) may require custom serialization logic.

  • store:

    store can handle complex data types, including objects and arrays, as it uses the browser's storage mechanisms (Local Storage, Session Storage, Cookies) which support stringifying data. Complex data must be serialized (e.g., using JSON.stringify) before storing and deserialized when retrieving.

Ease of Use: Code Examples

  • js-cookie:

    js-cookie Example

    import Cookies from 'js-cookie';
    
    // Set a cookie
    Cookies.set('name', 'value', { expires: 7 }); // Expires in 7 days
    
    // Get a cookie
    const value = Cookies.get('name');
    console.log(value);
    
    // Delete a cookie
    Cookies.remove('name');
    
  • localforage:

    localforage Example

    import localforage from 'localforage';
    
    // Set an item
    await localforage.setItem('key', { name: 'value' });
    
    // Get an item
    const item = await localforage.getItem('key');
    console.log(item);
    
    // Remove an item
    await localforage.removeItem('key');
    
  • store2:

    store2 Example

    import store2 from 'store2';
    
    // Set a value
    store2('namespace').set('key', 'value');
    
    // Get a value
    const value = store2('namespace').get('key');
    console.log(value);
    
    // Remove a value
    store2('namespace').remove('key');
    
  • idb-keyval:

    idb-keyval Example

    import { set, get, del } from 'idb-keyval';
    
    // Set a value
    await set('key', 'value');
    
    // Get a value
    const value = await get('key');
    console.log(value);
    
    // Delete a value
    await del('key');
    
  • redux-persist:

    redux-persist Example

    import { createStore } from 'redux';
    import { persistStore, persistReducer } from 'redux-persist';
    import storage from 'redux-persist/lib/storage'; // defaults to localStorage
    
    const persistConfig = { key: 'root', storage };
    const persistedReducer = persistReducer(persistConfig, rootReducer);
    const store = createStore(persistedReducer);
    const persistor = persistStore(store);
    
  • store:

    store Example

    import store from 'store';
    
    // Set a value
    store.set('key', 'value');
    
    // Get a value
    const value = store.get('key');
    console.log(value);
    
    // Remove a value
    store.remove('key');
    
How to Choose: js-cookie vs localforage vs store2 vs idb-keyval vs redux-persist vs store
  • js-cookie:

    Choose js-cookie if you need a straightforward solution for managing cookies in the browser. It provides a simple API for setting, getting, and deleting cookies, making it easy to handle cookie-based data without dealing with the complexities of the document.cookie API.

  • localforage:

    Choose localforage if you want a library that provides a simple, promise-based API for storing data in the browser using various storage backends (IndexedDB, WebSQL, and LocalStorage). It automatically selects the best available storage option, making it versatile and easy to use for both small and large data sets.

  • store2:

    Choose store2 if you want an enhanced version of the store library with support for namespacing, expiration, and better handling of complex data types. It is suitable for projects that require more advanced features while still maintaining a simple and intuitive API.

  • idb-keyval:

    Choose idb-keyval if you need a simple and lightweight wrapper around IndexedDB for storing key-value pairs. It is ideal for projects that require asynchronous storage with a minimal API and good performance.

  • redux-persist:

    Choose redux-persist if you are using Redux for state management and want to automatically persist your Redux store to local storage (or other storage engines) between page reloads. It helps maintain application state across sessions with minimal configuration.

  • store:

    Choose store if you need a simple and lightweight library for storing key-value pairs in the browser. It provides a unified API for working with Local Storage, Session Storage, and Cookies, making it easy to store data across different storage mechanisms without worrying about the implementation details.

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