c15t decides who sees the banner per region, and its releases land on a canary branch

The banner renders from your bundle, not from a snippet

The core claim is architectural. c15t gives you a cookie banner, a preference dialog and consent gated scripts for React, Next.js, Vue, Nuxt, Svelte, Astro, TanStack Start and plain HTML, and the README states that the banner ships in your bundle and renders with your app rather than arriving from a third party snippet that loads after the page.

That single difference changes the failure modes. No consent UI means no layout shift when a late request fails, and no separate origin serving the banner means no additional third party on the page. It also means the styling is yours to maintain, which is the cost: the README offers prebuilt components with a theme system, or your own UI on headless hooks and composables.

The project describes itself as an open standard for cookie banners in its own image alt text, and as a developer-first CMP in the repository description. Whether that framing survives contact with a compliance review is a question for your legal team, not for this README.

Consent-gated loaders for 40+ vendors, and four standards it claims to implement

Once a visitor picks, the job of a CMP is to make analytics stop. c15t ships ready-made loaders covering more than 40 vendors, and the README names Google Tag Manager, GA4, Meta Pixel and PostHog among them. The implication is that you declare which tags belong to which consent category rather than writing a loader per vendor.

Standards support is listed as built in: Google Consent Mode v2, IAB TCF 2.4, IAB GPP and Global Privacy Control. Those four matter because they are what a regulator or an ad platform will ask about, and supporting TCF is not something a hand rolled banner can claim retroactively.

Regional policy is the other half. The README says policies decide who sees a banner, with opt-in for visitors in the EU, opt-out for some US states, or rules you write yourself. That implies a policy engine evaluated per visitor rather than a single global banner, which is why the server rendering story below exists at all.

Server rendered pages resolve the policy before the browser asks

On Next.js, Nuxt, Astro, TanStack Start and SvelteKit, c15t resolves each visitor's policy on the server so the banner can ship in the first HTML rather than waiting on a request from the browser. For a consent banner this is not a performance nicety. A banner that appears late is often the banner a visitor has already scrolled past, and a script gated behind consent that fires late can outlive a rejection.

The trade is that server resolution needs a place to look up the previous decision. c15t needs somewhere to keep policies and consent records, and the README lists three choices: hosted on Inth, on a backend you run yourself, or in the browser only. The examples directory makes the second one concrete with an examples/self-host/ project alongside framework examples for astro-static, nuxt-static, nextjs-pages-router and others.

Browser only storage is the option with the smallest infrastructure and the weakest story across devices and across clearing cookies, so treat it as the third choice rather than the default.

One package per framework, and no install command in the README

Installation is documented as a matrix rather than a command, and it is worth reading as a table because the package names are not uniform. React 18 and 19 use the c15t package and import from c15t/react. Next.js 15 and 16 use the same c15t package but import from c15t/next. Vue 3 imports from c15t/vue/vue-plugin, while Nuxt 3 and 4 import from c15t/vue as a Nuxt module. Astro 5, 6 and 7 import from c15t/astro, TanStack Start from c15t/tanstack-start, and a headless JavaScript setup from c15t or c15t/runtime.

Two entries break the pattern. Svelte 5 and SvelteKit use a separately scoped package, @c15t/svelte, for both install and import. And the no build step path for Webflow, WordPress, Framer and Squarespace uses @c15t/browser, loaded from a CDN through a script tag.

The README does not print install commands, so the package names above are the whole instruction it gives, and each cell links to a framework quickstart page on c15t.com/docs. That is a real limitation for anyone working from the repository alone: the version constraints on each framework are given as prose ranges rather than as peer dependencies you can inspect before installing.

A canary branch shipping prerelease versions by default

The repository defaults to the canary branch, and the three most recent releases are prereleases: [email protected] and @c15t/[email protected], both published on 2026-10-14, alongside @c15t/[email protected] from the same day. Note the version offset between the core package and the UI package, which means the packages do not share a single lockstep version number.

The last push was on 2026-10-15, one day after those tags. Development is clearly moving faster than the release cadence, which is normal for a young CMP and is exactly why a version range needs to be pinned in a lockfile rather than floated.

The repository itself shows the tooling of a large TypeScript monorepo: turbo.json drives task orchestration, bunfig.toml and bun.lock place Bun as the runtime, renovate.json handles dependency updates, and knip.ts, oxlint.config.ts and oxfmt.config.ts point to a lint and format stack built on Oxc tooling rather than ESLint and Prettier. There are dedicated benchmarks packages for core, next bundle size, react, nuxt, tanstack-start, sveltekit and astro, which tells you bundle size is treated as a tracked property of this project.

Licence, security files, and what a reviewer will ask first

Licensing is Apache-2.0 with the file at the root and a NOTICE file beside it, so embedding the runtime in a commercial site carries the usual attribution and patent conditions rather than a copyleft obligation.

Two files at the root are aimed at exactly the audience that has to approve a consent banner. SECURITY.md is the disclosure route, and security-hardening.md is a written position on hardening. AGENTS.md, CLAUDE.md, .cursor/ and .agents/ directories plus a skills-lock.json show that the project ships conventions for automated coding tools, which is a signal about how the codebase is meant to be modified.

The claim a reviewer will push back on first is the adoption figure. The README states c15t is used by 2,100 or more sites and names expo.dev, zed.dev, unkey.dev, mintlify.com and sazabi.com, pointing at a Wappalyzer listing rather than at a case study per site. That is a self reported count with a public verification path, which is more than most CMPs offer, and it is still not an audit.

Editorial conclusion

c15t is the right pick when a third party script snippet is unacceptable to you or your reviewers, and when you can afford to own a consent backend, since policies and consent records need somewhere to live and the project offers hosted, self-hosted and browser only as three different compliance postures. It is a poor fit if you need a proven vendor audit trail in the box. Before adopting, read the security-hardening.md and SECURITY.md files at the repository root, and pin a version deliberately: the recent releases listed are canary prereleases such as [email protected] published on 2026-10-14 from the canary default branch, so a careless range would put prerelease code in production.

Frequently asked questions

Official sources

1. c15t/c15t on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases