Frontend-Only Mode
Most open-source cookie consent tools are frontend-only by design — a banner script, a preference toggle, done. @consenti/ui works exactly the same way when you run it standalone: npm install @consenti/ui, zero backend, zero runtime dependencies. The difference is what you get once it's running — a widget API surface, event system, and integration ecosystem closer to what a hosted SaaS CMP offers, not what a banner-only widget offers.
@consenti/ui alone — no @consenti/api, no server, no account. Add the backend later, any time, without changing your widget config, if you want server-side consent records or a dashboard. See Consenti, What-Why-How? for how the two packages relate.Why frontend-only Consenti is a different tier
Compared to banner-only widgets, Consenti is genuinely good at the one thing they do — standalone widget covers a lot more ground:
| Capability | Consenti (frontend-only) | Typical banner-only widget |
|---|---|---|
| Widget API methods | 31 — getConsent, hasConsent, showModal, reConsent, setProfile, switchLocale, and more | A handful — usually just accept/reject/show |
| DOM events | 8 — bannerInitialized, consentSubmitted, forgotten, parentalConsentRequired, and more | None, or a single callback option |
| Framework integration | Native React hooks, Vue composables, Angular services — plus Vanilla ESM/UMD | Vanilla script tag; framework wrapping is on you |
| Analytics/tag-manager mappers | GTM/Consent Mode v2, Adobe, Meta, Microsoft Clarity, Twilio Segment, generic purpose/category — typed, built in | Usually none — you write the mapping code yourself |
| Accessibility | Focus trap, ARIA roles, keyboard nav, screen-reader announcements, targeting WCAG 2.x AA | Varies widely, rarely a stated target |
| i18n | Per-locale translations with BCP 47 resolution (exact → language prefix → default) | Manual string replacement, if supported at all |
| Global Privacy Control (GPC) | Built in, with `true` / `'strict'` modes | Rarely built in |
| Cross-tab sync | Built in via BroadcastChannel | Not typically handled |
| Cookie auto-discovery | `@consenti/scanner` — local CLI crawler, run on demand or in CI | Not included — declare cookies by hand |
| Runtime dependencies | Zero — browser built-ins only | Usually also zero — this one is a tie |
Get started
- Installation — package install, ESM/UMD/subpath exports
- Minimal Setup — smallest possible working config
- How Consent Flow Works
- How Auto-Detection Works — jurisdiction resolved client-side, no network call
API surface
- API Methods — all 31 methods: state (
getConsent,hasConsent,isCategoryGranted...), UI control (showModal,hideBanner...), lifecycle (reConsent,forgetMe,destroy...) - DOM Events — all 8 events, plus
ConsentScript/CategoryScript/ConsentAction/BannerTriggerhelpers and declarativedata-consenti-*attribute-based script gating, no hand-written JS required - Plugin API —
ConsentiWidgetAPIreference, lifecycle hooks, example plugins
Framework integrations
- Framework Guides — React, Vue, Angular, Next.js, Nuxt
- Framework Integrations guide — hooks, composables, services in context
Analytics & tag-manager integrations
Typed consent mappers ship in @consenti/ui for each of these — no hand-rolled mapping code:
- GTM & Google Consent Mode v2
- Adobe Analytics & Experience Platform
- Meta Pixel & Conversions API
- Microsoft Clarity
- Twilio Segment
- Hotjar & Others
Theming & configuration
- Custom Themes & Dark Mode — CSS custom properties, no Shadow DOM
- Themes reference
- Configuration Reference
- Advanced Configuration
- Profiles (Appearance & Text) and Advanced Profiles
Cookie discovery
No crawler ships inside the widget itself — that would bloat the bundle for a task you only need occasionally. Instead, @consenti/scanner is a separate, local CLI: it crawls your site under none/reject-all/accept-all consent states and reports undeclared third-party trackers, fully offline. Run it once during setup, or wire it into CI.