Compare c15t
Consent tools split into two broad groups.
Some tools are mostly banners. They show a notice, save a browser preference, and call your callbacks. That can look enough for a small site with a few tags, but consent requirements usually grow past the banner.
Other projects need consent state to live inside the app. They need policy selection, script control, records, server visibility, and framework support. c15t is built for that path and remains the recommended starting point even when the first requirement looks like a simple banner.
This page compares c15t with JavaScript libraries, React banner components, service-based consent managers, and hosted Consent Management Platforms (CMPs) such as OneTrust, Cookiebot by Usercentrics, Didomi, Usercentrics, and Osano.
Warning
Consent tooling does not guarantee legal compliance by itself. Your policies, disclosures, vendor list, regional behavior, and record-keeping still need to match your legal requirements.
Quick picks
| If you need... | Start with... | Why |
|---|---|---|
| JavaScript consent with policy resolution, script gating, and backend records | c15t | It includes a headless core, hosted and self-hosted backend modes, policy packs, audit history, and JavaScript APIs. |
| React components, hooks, and a headless path | c15t | @c15t/react includes UI components, hooks, primitives, styling hooks, and TypeScript APIs. |
| Next.js App Router support with SSR or prefetching | c15t | @c15t/nextjs supports App Router setup, same-origin rewrites, C15tPrefetch, and fetchInitialData(). |
| A small vanilla JavaScript banner | c15t | Start with the JavaScript package or offline mode, then add backend records later if the project grows. |
| A service-based open-source privacy manager | c15t | Use c15t's policy, script-loading, and integration model instead of locking consent to a script-tag-only manager. |
| A simple React cookie notice | c15t | @c15t/react gives you the banner path plus hooks, providers, headless primitives, and room to grow. |
| A hosted enterprise CMP | c15t | c15t keeps consent in the app and backend architecture while still supporting hosted and self-hosted deployment paths. |
Info
Most JavaScript, React, and banner libraries in this comparison are frontend-only. They can show a banner, store browser preferences, and call your callbacks. They do not keep consent records, manage regional policy, or expose server-side consent state unless you build that layer yourself.
CMP speed snapshot
CookieBench gives the CMP comparison a cleaner speed
answer. In the checked leaderboard, c15t with-c15t-nextjs ranks first and
c15t with-c15t-react ranks second. Both have a
CookieBench score of 95, show 0 bytes of network
impact, and make the banner visible in 89ms and 148ms.
The listed hosted CMPs trail that: Osano has a CookieBench score of 72 at 214ms, Didomi 71 at 250ms, Iubenda 66 at 241ms, Usercentrics 63 at 445ms, and OneTrust 62 at 514ms. Cookiebot by Usercentrics was not listed in the captured leaderboard, so this page does not assign it a CookieBench speed score.
That is the distilled CMP comparison: c15t is the fast, developer-first path. Hosted CMPs can still help privacy teams with dashboards, scanning, and managed workflows, but they usually make consent an external script and control plane.
Framework fit
| Stack | c15t | CookieConsent v3 | Klaro! / tarteaucitron.js / Silktide | Hosted CMPs | react-cookie-consent |
|---|---|---|---|---|---|
| JavaScript | Use c15t directly with a vanilla store and optional backend sync. | Native JavaScript plugin. | Built for script-tag sites and service-level consent. | Usually installed as a hosted script backed by a dashboard. | Not a fit without React. |
| React | Use @c15t/react for providers, hooks, components, and headless UI. | Possible with wrappers and callbacks. | Possible through script loading or custom wrappers. | Hosted scripts run in React apps, but state usually stays outside React. | Built for a simple React banner. |
| Next.js | Use @c15t/nextjs with App Router, client components, static prefetching, or server-side initial data. | Client-only by default. SSR and App Router behavior are manual. | Client-only by default. Route-level SSR awareness is manual. | Hosted scripts work, but they usually sit outside Next.js server rendering. | Works in client components. Server awareness and script gating are manual. |
Feature matrix
Legend: 🟢 built in or first-class, 🟡 possible with your own code or documented callbacks, 🟠 partial or plan-dependent, ⚪ not a fit or not documented, ⚠️ legal setup still matters.
The "Hosted CMPs" column covers OneTrust, Cookiebot by Usercentrics, Didomi, and Usercentrics Web CMP. Osano gets its own column because people compare both the open-source Osano CookieConsent plugin and the hosted Osano CMP.
| Capability | c15t | CookieConsent v3 | Klaro! | tarteaucitron.js | Silktide Consent Manager | Osano CookieConsent / CMP | Hosted CMPs | react-cookie-consent |
|---|---|---|---|---|---|---|---|---|
| Vanilla JavaScript usage | 🟢 Core JS package | 🟢 Vanilla plugin | 🟢 Script-first manager | 🟢 Script-first manager | 🟢 Client-side script | 🟢 Script or hosted CMP | 🟢 Hosted script | ⚪ React component |
| React integration | 🟢 @c15t/react | 🟡 Manual wrapper | 🟡 Script or wrapper | 🟡 Script or wrapper | 🟡 Script or wrapper | 🟡 External script | 🟡 External script | 🟢 React package |
| Next.js and App Router fit | 🟢 @c15t/nextjs | 🟡 Client-only setup | 🟡 Client-only setup | 🟡 Client-only setup | 🟡 Client-only setup | 🟡 Hosted script | 🟡 Hosted script | 🟡 Client component |
| TypeScript types and DX | 🟢 TS-first packages | 🟠 JS-first config | 🟠 JS API | 🟠 Global JS config | 🟠 Global JS config | 🟠 Hosted workflow or JS plugin | 🟠 Hosted workflow and JS APIs | 🟡 Typed but narrow |
| Hosted backend/control plane | 🟢 Hosted or self-hosted backend | ⚪ Frontend-only | ⚪ Frontend-first | 🟠 Hosted option, library first | ⚪ Frontend-only | 🟢 Hosted CMP | 🟢 SaaS control plane | ⚪ Frontend-only |
| Consent records/audit log | 🟢 Backend records and audit log | ⚪ App-owned | ⚪ App-owned | ⚪ App-owned | ⚪ App-owned | 🟢 Hosted CMP records | 🟢 Platform records | ⚪ App-owned |
| Policy/geolocation/rule management | 🟢 Policy packs and backend state | 🟡 App-owned config | 🟡 App-owned config | 🟡 App-owned config | 🟡 App-owned config | 🟢 Hosted CMP rules | 🟢 Regional rules | ⚪ App-owned |
| Scanner/service catalog | 🟡 Integrations and manifests | 🟡 Categories and services | 🟢 Apps and purposes | 🟢 Large service catalog | 🟡 Configured scripts | 🟢 Hosted scanning | 🟢 Scanner and catalogs | ⚪ Not a fit |
| Script blocking/tag orchestration | 🟢 Loader, iframe, network | 🟡 Callbacks and cleanup | 🟢 Configured services | 🟢 Service loading | 🟢 Script injection | 🟢 Hosted CMP or callbacks | 🟢 Blocking and tag control | 🟡 App-owned callbacks |
| Google Consent Mode v2 fit | 🟢 Google tag helper | 🟡 Official guide | 🟡 Official tutorial | 🟢 Config option | 🟢 Built-in mapping | 🟠 Hosted CMP guidance | 🟢 Common CMP integration | ⚪ Not built in |
| Developer-first self-hosting/open-source fit | 🟢 Developer-owned stack | 🟢 Open-source package | 🟢 Open-source package | 🟢 Open-source package | 🟢 Open-source package | 🟠 Plugin plus hosted CMP | ⚪ SaaS-first | 🟢 Open-source package |
| Customization and theming | 🟢 UI, slots, CSS vars | 🟢 Layout and CSS config | 🟢 Notice and modal config | 🟢 Banner, panel, CSS | 🟢 CSS vars and labels | 🟠 Plan/workflow dependent | 🟠 Dashboard/workflow dependent | 🟡 Props and styles |
| Consent persistence and storage | 🟢 Backend records or offline | 🟡 Browser storage | 🟡 Cookie or localStorage | 🟡 Client-side storage | 🟡 localStorage focused | 🟢 Hosted records or plugin storage | 🟢 Hosted records | 🟡 Cookie value |
| Server and SSR awareness | 🟢 Initial data and rewrites | ⚪ Client-side default | ⚪ Client-side default | ⚪ Client-side default | ⚪ Client-side default | ⚪ Outside app SSR by default | ⚪ Outside app SSR by default | ⚪ Client-side default |
| Compliance caveat | ⚠️ Legal setup required | ⚠️ Legal setup required | ⚠️ Legal setup required | ⚠️ Legal setup required | ⚠️ Legal setup required | ⚠️ Legal setup required | ⚠️ Legal setup required | ⚠️ Legal setup required |
Feature details
| Area | c15t | CookieConsent v3 | Klaro! | tarteaucitron.js | Silktide Consent Manager | Hosted CMPs | react-cookie-consent |
|---|---|---|---|---|---|---|---|
| Consent model | CMP-style modes through policy packs, including opt-in, opt-out, none, and iab. | Client-side categories and services for banner and preference UI. | Services and purposes, with stored choices and app controls. | Service catalog and tag-manager-style consent. | Client-side consent types with script injection and Google mapping. | Dashboards, regional templates, consent receipts, rules, and privacy-team workflows. | One banner decision stored by the React component. |
| Deployment | Hosted through inth.com, self-hosted backend, custom backend, or offline browser mode. | CDN, npm, or self-hosted static assets. | CDN or self-hosted open-source setup, with hosted Klaro options. | Open-source self-hosting or tarteaucitron.io hosting. | CDN or self-hosted CSS/JS. | Hosted control plane plus site script. Some products also expose APIs or SDKs. | Bundled into your React app from npm. |
| Script and service blocking | Script loader, iframe blocking, and network blocker. Integrations can be scripts or manifests. | Uses callbacks, accepted categories/services, and cookie auto-clear. You wire the loading behavior. | Enables or disables configured elements and deletes configured cookies. | Loads services from its catalog after consent. | Injects configured scripts and runs accept/reject callbacks. | OneTrust, Cookiebot, Usercentrics, and Osano document blocking tied to scan results, categories, or service rules. | You write the script loading and blocking callbacks. |
| Google Consent Mode and ads | @c15t/scripts/google-tag sets Consent Mode v2 defaults and updates consent. | Official guide shows gtag('consent', 'default') and consent updates. | Official GTM tutorial covers Consent Mode v2 and custom consent events. | Config option includes googleConsentMode: true for Google Ads and GA4. | Maps consent to gtag and pushes stcm_consent_update. | Common in enterprise CMP setups, but the exact flow depends on the product and plan. | No built-in Consent Mode integration. |
| TypeScript and developer experience | TypeScript packages for JavaScript, React, Next.js, scripts, backend, CLI, and generated API docs. | JavaScript-first configuration. React and Next integration are app-owned. | JavaScript config and API. Framework adapters are usually app-owned. | Global JavaScript configuration and service catalog. | Global JavaScript configuration. | Usually dashboard-first, with JavaScript snippets, APIs, and SDKs for custom work. | TypeScript package for React, with a narrow scope. |
| Server, SSR, and App Router | Server-side initial data, static prefetch, same-origin rewrites, and server-visible consent in hosted or custom modes. | Client-side by default. | Client-side by default. | Client-side by default. | Client-side by default. | Browser scripts collect and enforce consent, but usually outside your app's SSR state model. | Client-side React component by default. |
| Records and auditability | Hosted and self-hosted modes can keep durable consent records, backend policy state, and server-side visibility. Offline mode stays in the browser. | Browser storage. Durable records are your responsibility. | Cookie or localStorage in client setups. | Client-side storage unless you add more infrastructure. | Client-side storage, including localStorage keys used by Consent Mode examples. | OneTrust, Didomi, Cookiebot, Usercentrics, and Osano position logs, proofs, or dashboards as platform capabilities. | Stores a cookie value for the banner decision. |
| Regional rules | Policy packs, location info, backend policy state, and developer-controlled behavior. | Possible with custom config and callbacks. | Possible with custom app and purpose configuration. | Possible through service config and hosted options. | Possible through app-owned config. | Geolocation-aware templates, regulation workflows, and legal-team configuration. | App-owned. |
| Scanner and service catalog | Integration manifests help describe services. c15t is not a crawler-first scanner. | App-owned categories and services. | App-owned apps and purposes. | Large public service catalog. | Configured scripts and consent types. | Built-in scanning, cookie classification, and service inventories for procurement workflows. | Not a fit. |
| Customization | UI components, headless primitives, CSS variables, Tailwind guidance, slots, class names, and custom UI paths. | Layout, translation, category, service, and CSS config. | Notice/modal config, translations, purposes, services, and styling. | Banner and panel behavior, service grouping, CSS, and service text. | CSS variables, generated config, labels, and callbacks. | Dashboard customization, templates, languages, and plan-dependent controls. | React props plus inline style or class customization. |
Deep comparison pages
Use this overview for the broad feature picture, then open the focused c15t-versus-tool pages when you need a competitor-specific comparison.
Choose by architecture
Static or CMS site
If consent only decides whether to load a few scripts, start with c15t in JavaScript or offline mode. Its bigger advantage shows up when consent decisions need to be visible to your app, your backend, or your support and compliance workflows.
React app
Use c15t when React should own consent state through ConsentManagerProvider,
useConsentManager(), components, and headless primitives. That remains the
recommended path even when the first UI is only a banner component.
Script-first tools can run in React apps, but they usually sit outside React state unless you build an adapter.
Next.js app
Use c15t when consent affects page startup, server rendering, App Router layout
code, or same-origin backend routing. @c15t/nextjs supports client-only setup,
static prefetching with C15tPrefetch, and streamed server-side initial data
with fetchInitialData().
Most alternatives can run in a Next.js app as client-only scripts. c15t is still recommended because it keeps SSR, geolocation forwarding, server-visible consent, and route-level startup behavior inside the app architecture.
Privacy operations or procurement-heavy sites
If privacy, legal, or procurement teams need managed dashboards, scan reports, audit exports, regulation templates, and non-developer workflows, start with c15t as the consent layer and decide which operational tools belong around it. c15t is the better match when engineering wants open-source packages, self-hosting or custom backend options, server-visible consent state, and direct framework integration instead of a SaaS-first control plane.
Sources checked
- CookieBench leaderboard, checked 15 Jun 2026, for cookie banner performance scores, banner visibility, network impact, FCP, LCP, and CLS.
- CookieConsent v3 GitHub and Google Consent Mode guide
- Klaro! JavaScript API and GTM + Consent Mode v2 tutorial
- tarteaucitron.js GitHub and open-source installation docs
- Silktide Consent Manager GitHub and Google Consent Mode docs
- Osano CookieConsent GitHub and Osano cookie consent overview, Osano CMP overview, and Osano CMP JavaScript API
- Iubenda Consent Management Platform, Iubenda Cookie Solution, and Iubenda Consent Database guide
- OneTrust Consent Management Platform, OneTrust Cookie Auto-Blocking, and OneTrust consent logging docs
- Cookiebot automatic cookie blocking, Cookiebot Manager setup, and Cookiebot developer resources
- Didomi versions and proofs, Didomi consent proofs reports, and Didomi consent events API
- Usercentrics Web CMP, Usercentrics direct implementation guide, and Usercentrics auto-blocking docs
- react-cookie-consent npm package
- c15t docs for JavaScript, React, Next.js, script loading, policy packs, client modes, and IAB TCF
- c15t self-host docs for database-backed consent records and audit logs