CookieConsent v3: a vanilla JS cookie banner you configure yourself

What CookieConsent v3 actually decides for you

The project describes itself as a lightweight and GDPR compliant cookie consent plugin written in plain javascript, and the README points to a playground and a separate documentation site. What it does not do is decide which cookies exist on your site. The plugin renders the banner, stores the visitor's answer, and exposes a small API so your own code can ask whether a category was accepted. Everything upstream of that, meaning the category names, the cookie descriptions and the scripts that should stay blocked until consent, is content you write. The audience is therefore a developer who can edit the page's script tags and is willing to own that configuration. If you are looking for a service that scans your site, fills in a cookie table and keeps a server-side record of every consent, this is not that product. The MIT licence and the vanilla JS implementation mean the whole thing can be served from your own origin, which is the main reason teams pick it over a hosted consent management platform.

How the plugin, the config object and the consent store fit together

The architecture visible in the repository is a plain front-end library with no server component. The package exposes two builds, dist/cookieconsent.umd.js and dist/cookieconsent.esm.js, which is why package.json sets main and module to different files. There is also a core build driven by rollup-core.config.mjs alongside the full build driven by rollup-full.config.mjs, so the project deliberately ships more than one bundle size. The types are published separately in the types directory with types/index.d.ts as the entry point, which means a TypeScript project gets the config shape without a separate @types package. At runtime the flow is: your page loads the plugin, the plugin reads a config object you pass in, renders the consent UI, and persists the visitor's choice. Your scripts then query that stored state before running. The repository layout supports this reading: src holds the source, dist holds the built bundles, tests holds a Jest suite run with jest --runInBand --coverage, and demo contains separate folders including demo_basic, demo_gtm and demo_iframemanager. Those three demo folders are the clearest signal of intended use, since they show the plugin being combined with Google Tag Manager and with an iframe manager rather than working alone.

Installing vanilla-cookieconsent from npm and showing a first banner

The npm package is named vanilla-cookieconsent, not cookieconsent, which is worth checking before you run anything. The README credits Till Sanders with creating and maintaining the npm package, and package.json confirms the name field. The README gives no install command of its own, so the package name and the module entry points in package.json are the concrete facts to work from, and the documentation site at cookieconsent.orestbida.com is where the full config reference lives. The repository does show the two published entry points, which is what an import resolves against.

"main": "dist/cookieconsent.umd.js",
"module": "dist/cookieconsent.esm.js",

Those two fields are the reason a bundler and a plain script tag load different files. The README also lists the scripts the project itself runs during development, including the watch build and the test suite.

"dev": "rollup --config ./rollup-full.config.mjs --watch",
"test": "jest --runInBand --coverage --silent ./tests"

What the repository does not contain is a copy-paste initialisation example, so the config object you pass to the plugin has to come from the documentation site rather than from the README. To see the banner before writing any config, the README points to the playground at playground.cookieconsent.orestbida.com and to a collection of examples on Stackblitz. The plugin does not block scripts for you, so whatever guard you write around your analytics loader is your own code, and the demo_gtm folder is the repository's own indication of how that integration is expected to look.

Where CookieConsent v3 leaves work on your side

The limitation that matters most is the one implied by the design: the plugin is a UI and a state store, not a compliance engine. It will not detect which cookies your site sets, will not generate the cookie table, and will not tell you whether your category definitions match what your scripts actually do. If a third-party tag fires before your guard runs, the banner's presence does nothing about it. That is a real failure mode, and it is a code-ordering problem rather than a plugin bug. There is also no backend in the repository, so consent records stay in the browser. If your organisation needs a server-side log of who consented to what and when, you would have to build that yourself, and the README does not describe such a feature. The repository does not document rollback or migration steps between major versions either, which matters because the release history shows a v3.0.0 in January 2024 and a v3.1.0 in February 2025. Anyone upgrading from v2 should expect to read the documentation site rather than the README. Finally, the plugin is the wrong tool if your pages are rendered by a framework that already has a consent integration you trust, since adding a second banner creates two sources of truth for the same decision.

CookieConsent v3 compared with a hosted consent platform

The natural alternative is a hosted consent management platform, and the search data around this project shows that comparison happening in practice, with queries naming other vendors. The difference in approach is where the logic lives. A hosted CMP runs a script from the vendor's domain, keeps the consent record on the vendor's servers, and usually provides a dashboard where a non-developer can edit the banner text and review consent statistics. CookieConsent v3 inverts that. The bundle is served from your origin, the record is stored client-side, and the configuration is a JavaScript object in your repository. The trade-off is control against operational work. You get no vendor dependency, no third-party request on page load, and no per-pageview pricing, because the licence is MIT. You also get no dashboard, no audit log and no support contract. For a small team that already manages its own tags, that exchange is favourable. For a marketing team that needs to change banner wording without a deploy, it is not, because every text change in this plugin is a code change.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and the most recent push recorded is 2026-07-23. The release history shows v3.0.0 in January 2024, v3.0.1 in April 2024 and v3.1.0 in February 2025, so major-version churn is infrequent but the gap between v3.1.0 and the latest push is long enough that you should check the releases page before pinning a version. The build uses Rollup with separate full and core configs, plus Babel and ESLint, and the test suite runs under Jest with jsdom, so a contributor needs that toolchain rather than a single bundler. The published package only includes dist and types, which keeps the install small but means you cannot read the source from node_modules without going back to the repository. The licence is MIT, stated in both the README badge and the LICENSE file. In practical terms that permits commercial use and modification, and it removes the vendor-contract question that a hosted CMP raises. It does not shift any regulatory obligation onto the maintainer, and nothing in the repository constitutes legal advice about whether your banner text satisfies a given jurisdiction.

Editorial conclusion

Adopt CookieConsent v3 if you control your own script tags and want a self-hosted banner without a vendor account. Do not adopt it if you expect the plugin to classify your cookies for you, or if you need a hosted dashboard and audit trail. Before writing any config, confirm that the npm package name is vanilla-cookieconsent and not cookieconsent, and open the playground at playground.cookieconsent.orestbida.com to see the banner before you commit to it.

Frequently asked questions

Official sources

1. License: MIT
2. orestbida/cookieconsent on GitHub
3. Project website
4. README
5. Releases