js-cookie vs universal-cookie vs react-cookie vs universal-cookie-express

Managing Cookies in JavaScript Applications Across Environments

js-cookie, react-cookie, universal-cookie, and universal-cookie-express are npm packages designed to simplify cookie handling in JavaScript applications. js-cookie is a lightweight, framework-agnostic utility for reading, writing, and deleting cookies in the browser. react-cookie builds on top of cookie management specifically for React applications, offering hooks and context-based APIs. universal-cookie extends cookie operations to work consistently across both client and server environments (e.g., in Next.js or Remix apps), using the same API regardless of execution context. universal-cookie-express is a companion package that integrates universal-cookie with Express.js servers, enabling cookie parsing and serialization within Express middleware and route handlers.

Package	Downloads	Stars	Size	Issues	Publish	License

js-cookie	16,092,656	22,789	26.2 kB	3	3 years ago	MIT
universal-cookie	1,893,519	206	54.4 kB	19	9 months ago	MIT
react-cookie	855,193	206	71.3 kB	19	9 months ago	MIT
universal-cookie-express	33,299	206	5.58 kB	19	9 months ago	MIT

Managing Cookies in JavaScript: js-cookie vs react-cookie vs universal-cookie vs universal-cookie-express

Handling cookies seems simple until you add server-side rendering, React hooks, or Express middleware into the mix. These four packages solve overlapping but distinct problems. Let’s cut through the confusion with real code and clear boundaries.

🍪 Core Purpose: What Each Package Actually Does

js-cookie is a tiny (~800 bytes minified), dependency-free library for browser-only cookie manipulation. It wraps document.cookie with a clean API.

// js-cookie: browser only
import Cookies from 'js-cookie';

Cookies.set('theme', 'dark');
const theme = Cookies.get('theme');
Cookies.remove('theme');

react-cookie provides React hooks (useCookies) that tie cookie values to component re-renders. It uses js-cookie under the hood but adds React integration.

// react-cookie: React hooks, browser only
import { useCookies } from 'react-cookie';

function ThemeToggle() {
  const [cookies, setCookie, removeCookie] = useCookies(['theme']);
  return (
    <button onClick={() => setCookie('theme', 'light')}>
      Current: {cookies.theme || 'default'}
    </button>
  );
}

universal-cookie offers a single API that works identically in browser and Node.js. You pass it a raw cookie string (from req.headers.cookie) or let it auto-detect the environment.

// universal-cookie: works everywhere
import Cookies from 'universal-cookie';

// In browser
const cookies = new Cookies();
cookies.set('auth', 'abc123');

// On server (e.g., Next.js getServerSideProps)
const cookies = new Cookies(req.headers.cookie);
const auth = cookies.get('auth');

universal-cookie-express is not a standalone cookie library. It’s a helper that connects universal-cookie to Express.js by parsing incoming cookies and serializing outgoing ones.

// universal-cookie-express: Express middleware glue
import { Cookies } from 'universal-cookie';
import { expressWrapper } from 'universal-cookie-express';

app.use((req, res, next) => {
  // Parse incoming cookies into req.universalCookies
  expressWrapper(req, res);
  
  // Now use universal-cookie instance
  const cookies = req.universalCookies;
  const token = cookies.get('token');
  
  // Set cookie will auto-write to res.setHeader
  cookies.set('visited', 'true');
  next();
});

🌐 Environment Support: Where Each Package Runs

Package	Browser	Node.js (SSR)	Express Integration
`js-cookie`	✅	❌	❌
`react-cookie`	✅	❌*	❌
`universal-cookie`	✅	✅	⚠️ Manual setup
`universal-cookie-express`	❌	✅ (with Express)	✅

* react-cookie breaks during SSR because it calls document.cookie, which doesn’t exist on the server.

If your app uses Next.js, Remix, or any SSR framework, avoid js-cookie and react-cookie for anything that runs on the server. They’ll throw ReferenceError: document is not defined.

🔁 Data Flow: How Cookies Move Through Your App

Scenario: Reading a user’s auth token during page load

With js-cookie (client-only):

// Only works after hydration
useEffect(() => {
  const token = Cookies.get('auth_token');
  if (token) setUser({ authenticated: true });
}, []);

→ Problem: Initial HTML shows unauthenticated state, then flashes to authenticated after JS loads.

With universal-cookie (SSR-safe):

// Next.js getServerSideProps
export async function getServerSideProps({ req }) {
  const cookies = new Cookies(req.headers.cookie);
  const token = cookies.get('auth_token');
  
  return {
    props: { user: token ? { authenticated: true } : null }
  };
}

→ Result: Correct initial HTML, no flash of unauthenticated UI.

Scenario: Setting a cookie after login

With react-cookie:

const [cookies, setCookie] = useCookies();

const handleLogin = async () => {
  const { token } = await api.login(credentials);
  setCookie('auth_token', token, { path: '/' });
};

→ Works fine in browser, but fails if called during SSR.

With universal-cookie + Express:

// Express route
app.post('/login', (req, res) => {
  const cookies = new Cookies(req.headers.cookie);
  cookies.set('auth_token', token, { httpOnly: true });
  
  // Manually write to response
  res.setHeader('Set-Cookie', cookies.getAll());
  res.json({ success: true });
});

With universal-cookie-express:

// Same route, but with expressWrapper
app.use(expressWrapper); // sets up req.universalCookies

app.post('/login', (req, res) => {
  req.universalCookies.set('auth_token', token, { httpOnly: true });
  // Cookie automatically added to response headers
  res.json({ success: true });
});

⚙️ API Differences: Method Signatures and Options

All packages support similar options (path, domain, expires, secure), but differ in how they’re applied.

Setting a secure, HTTP-only cookie:

// js-cookie (browser only — can't set httpOnly!)
Cookies.set('id', '123', { secure: true });
// Note: httpOnly is impossible in browser JS

// universal-cookie (server or browser)
const cookies = new Cookies();
cookies.set('id', '123', { httpOnly: true, secure: true });

// react-cookie (browser only — no httpOnly)
setCookie('id', '123', { secure: true });

// universal-cookie-express (Express server)
req.universalCookies.set('id', '123', { httpOnly: true, secure: true });
// Automatically included in Set-Cookie header

💡 Critical note: httpOnly cookies cannot be set from browser JavaScript — only from server responses. If you see httpOnly in a js-cookie or react-cookie example, it’s either ignored or misleading.

🧩 Integration Complexity

js-cookie: Drop-in. No setup.
react-cookie: Requires wrapping your app in <CookiesProvider> if you want SSR-like behavior (but still doesn’t work during actual SSR).
universal-cookie: Requires passing the raw cookie header on the server, and manually handling Set-Cookie headers in responses.
universal-cookie-express: Eliminates manual header handling in Express, but only works with Express.

🚫 When NOT to Use Each Package

Don’t use js-cookie if your app ever runs on a server (Next.js, Remix, etc.).
Don’t use react-cookie if you need to read cookies during server-side data fetching — it will crash.
Don’t use universal-cookie-express without universal-cookie — it’s just a thin wrapper.
Don’t use any of these if you only need to read/write cookies in a pure Express backend — native req.headers.cookie and res.cookie() (from cookie-parser) may suffice.

✅ Recommendation by Architecture

Your Stack	Best Choice(s)
Vanilla JS SPA	`js-cookie`
React SPA (no SSR)	`react-cookie` or `js-cookie`
Next.js / Remix (full-stack React)	`universal-cookie`
Express backend + universal-cookie	`universal-cookie` + `universal-cookie-express`
Express backend only	Built-in `cookie-parser` or native headers

💡 Final Thought

Cookie management isn’t one-size-fits-all. The right tool depends entirely on where your code runs:

Browser only? → js-cookie or react-cookie.
Browser + server? → universal-cookie.
Express backend using universal-cookie? → Add universal-cookie-express to reduce boilerplate.

Trying to force a browser-only library into an SSR app is the most common mistake — it leads to runtime errors and hydration mismatches. Match the package to your execution environment, and you’ll avoid hours of debugging.

js-cookie:
Choose js-cookie if you're working on a standard browser-based application without server-side rendering and need a minimal, battle-tested, zero-dependency library for basic cookie operations. It’s ideal for vanilla JS projects or when you want full control without React-specific abstractions.
universal-cookie:
Choose universal-cookie if your application runs in both browser and server environments (e.g., Next.js, Remix, or custom SSR setups) and you need a single cookie API that works everywhere. It’s the right choice when you must read or write cookies during server-side rendering or data loading.
react-cookie:
Choose react-cookie if you’re building a React application that runs only in the browser and you want React hooks like useCookies to manage cookies as part of your component state. Avoid it if your app uses SSR or needs to access cookies during server-side data fetching.
universal-cookie-express:
Choose universal-cookie-express only if you’re using Express.js on the backend alongside universal-cookie and need to parse incoming cookies from req.headers.cookie or serialize cookies into res.setHeader('Set-Cookie', ...). Do not use it standalone — it’s strictly an integration layer for Express.

js-cookie

universal-cookie

react-cookie

universal-cookie-express

JavaScript Cookie

A simple, lightweight JavaScript API for handling cookies

Works in all browsers
Accepts any character
Heavily tested
No dependency
Supports ES modules
Supports AMD/CommonJS
RFC 6265 compliant
Useful Wiki
Enable custom encoding/decoding
< 800 bytes gzipped!

👉👉 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.

Managing Cookies in JavaScript: js-cookie vs react-cookie vs universal-cookie vs universal-cookie-express

🍪 Core Purpose: What Each Package Actually Does

🌐 Environment Support: Where Each Package Runs

🔁 Data Flow: How Cookies Move Through Your App

Scenario: Reading a user’s auth token during page load

Scenario: Setting a cookie after login

⚙️ API Differences: Method Signatures and Options

🧩 Integration Complexity

🚫 When NOT to Use Each Package

✅ Recommendation by Architecture

💡 Final Thought

JavaScript Cookie

Installation

NPM

CDN

Basic Usage

Namespace conflicts

Encoding

Cookie Attributes

expires

path

domain

secure

sameSite

Setting up defaults

Converters

Read

Write

TypeScript declarations

Server-side integration

Contributing

Security

Releasing

Supporters

Authors