react-cookie-consent gives React apps a configurable consent bar

A component, a cookie and a callback, with nothing else

The project describes itself as a small, simple and customizable cookie consent bar for use in React applications, and the implementation matches that description closely. There is no provider to wrap your tree, no plugin system, no global store and no configuration file. You install the package, import the component, and render it wherever you want the bar to appear. The repository layout supports that reading: src/ holds the implementation, stories/ and .storybook/ hold the Storybook demo that the README links as the live demo, and package.json points main at dist/react-cookie-consent.umd.js, module at dist/react-cookie-consent.es.js and typings at dist/index.d.ts, with the published files limited to dist and src. The whole contract between the library and your application is three things: a component, a cookie, and a callback.

The whole install is one npm or yarn command

The README gives the install two ways, npm first and yarn second.

npm install react-cookie-consent

yarn add react-cookie-consent

Then you import the component into your React app.

import CookieConsent from "react-cookie-consent";

If you intend to set or remove the cookie yourself, the README notes you can optionally import Cookies, which comes straight from js-cookie.

import CookieConsent, { Cookies } from "react-cookie-consent";

The bare usage is a single element with your text as children.

<CookieConsent>This website uses cookies to enhance the user experience.</CookieConsent>

No props are required for it to render, which makes it easy to drop in a first version and then tune it.

Props control placement, wording, styling and expiry

The props table is where the customization lives. The location prop takes the strings top, bottom or none, defaults to bottom, and none disables the bar entirely. The visible prop takes show, hidden or byCookieValue and defaults to byCookieValue, meaning visibility is decided by whether a consent cookie already exists. The children prop takes a string or a React component for the content of the bar. disableStyles, a boolean defaulting to false, strips the default styling while still letting you pass your own through the style props. hideOnAccept defaults to true, so the component hides itself after acceptance, and the README points out that if you disable it you have to hide the bar yourself from inside onAccept. buttonText defaults to I understand and accepts a string or a React component. The style and buttonStyle props take inline style objects, and the example shows both a background color and a font size set that way. A cookieName prop lets you choose the name of the cookie that stores the decision, and an expires prop is set in days, with the example using 150.

onAccept reports whether the user clicked or scrolled

One prop carries behaviour rather than appearance. onAccept is a function called after the user clicks the accept button, and it is invoked with an object containing a boolean property acceptedByScrolling that indicates whether acceptance was triggered by scrolling rather than by the click. The README gives this example.

<CookieConsent
  onAccept={(acceptedByScrolling) => {
    if (acceptedByScrolling) {
      // triggered if user scrolls past threshold
      alert("Accept was triggered by user scrolling");
    } else {
      alert("Accept was triggered by clicking the Accept button");
    }
  }}
></CookieConsent>

A decline path exists too. The onDecline prop is called after the user clicks the decline button, and the decline button has to be enabled explicitly with enableDeclineButton.

<CookieConsent
  enableDeclineButton
  onDecline={() => {
    alert("nay!");
  }}
></CookieConsent>

Both handlers are the correct place to gate your analytics or marketing scripts, since they run at the moment of the decision rather than at page load.

Reading and clearing the decision from your own code

The package exports two helper functions for reading and resetting the stored value. getCookieConsentValue takes a cookie name and returns the stored value.

import CookieConsent, { Cookies, getCookieConsentValue } from "react-cookie-consent";

console.log(getCookieConsentValue("your_custom_cookie_name"));

resetCookieConsentValue removes the cookie on the client side.

import CookieConsent, { Cookies, resetCookieConsentValue } from "react-cookie-consent";

console.log(resetCookieConsentValue());

The README frames the reset function as the way to let a user change their consent. There is one condition attached: if you want the bar to appear again, you have to force the visible prop to show it. That is because the default visibility mode is byCookieValue, so simply deleting the cookie does not by itself force a re-prompt in every code path. The exports also include the Cookies object from js-cookie, which means you can read and write cookies yourself without adding js-cookie to your own dependency list.

The bar records a decision, it does not block anything

This is the limit worth being explicit about. The component shows a bar, records a choice in a cookie and calls your callback. Nothing in the documentation describes cookie categories, per category consent, blocking script loading before consent, or a server rendered consent state. In other words, the library is a presentation and persistence layer. Your own onAccept and onDecline handlers are what actually decide whether a third party script runs, and that is also where you can get it wrong: a script loaded in the document head before the user answers will already have run. The README mentions an accept on scroll option in its list of styling examples, where acceptance is triggered when the user scrolls past a threshold. That behaviour is convenient for engagement and it is worth reading closely if you are relying on it, because the same mechanism that raises acceptance rates also raises questions about whether a scroll is meaningful consent in your jurisdiction.

Two cookies, one of them legacy, and a version gap to check

The README has a section asking why there are two cookies, one of them named Legacy. That is a migration detail from the package own history, and it means a value written by an older version of the library may live under a different cookie name than the one your current code reads. The version numbers deserve attention for a second reason. The recent releases listed are 6.4.0, 6.2.3 and 6.2.1, with 6.4.0 dated 2021-09-23, while the package.json in the repository declares version 10.0.2. The repository is TypeScript, the build runs on Vite, the lint script is tsc --noEmit and the format script is prettier, so the current code is a later rewrite of the component the older tags refer to. The last push was on 2026-10-18, and the repository carries a renovate.json, a .husky/ directory and an .eslintrc, so the tooling is current even though the release history in the tags is old. Check which version npm actually resolves before you rely on any specific prop.

Editorial conclusion

Adopt react-cookie-consent if you need a consent banner in a React application today, and you want the choice stored in a cookie your own code can read so analytics scripts can be gated on it. Do not adopt it if you need per category consent, a server rendered consent state, or a solution that blocks cookies before your scripts load, since the component records a decision and renders a bar without doing either. Verify first by installing react-cookie-consent, rendering the component with an onAccept handler, then calling getCookieConsentValue with your cookie name, and note that the package.json version is 10.0.2 while the most recent tagged release is 6.4.0 from 2021-09-23, so check which build you actually get from npm.

Frequently asked questions

Official sources

1. License: MIT
2. Mastermindzh/react-cookie-consent on GitHub
3. Project website
4. README
5. Releases