---
title: c15t vs CookieConsent v3
description: Choose c15t when your application needs native consent state and a
  record backend. Compare CookieConsent's browser controls and the extra setup
  each approach needs.
group: reference
lastModified: "2026-10-10T16:01:45+01:00"
---
## Choose c15t to connect the interface, rules and records

c15t is the stronger fit when your application needs more than browser preferences. It connects framework components, consent rules, vendor integrations and a backend for records.

CookieConsent is a capable browser library with granular controls and custom styles. It installs as `vanilla-cookieconsent`. It is a separate project from c15t.

## Let Inth run your consent backend

You need a backend to store consent records outside the visitor's browser. [Inth](https://inth.com) builds c15t and hosts that backend and its database for c15t's framework integrations, browser package and headless API. Your consent interface and vendor controls stay in your application.

Connect your application to an Inth project with the [framework setup guide](/docs/frameworks). Inth also serves your consent policy, so static sites can use it without their own application server.

Offline mode keeps choices on the visitor's device and creates no remote consent records. Use it for development and tests, not production.

You can [self-host the c15t backend](/docs/self-host/overview) when your team needs to operate the service. Your team then owns the database, backups, updates and availability.

## Compare what you need to assemble

|What you need|c15t|CookieConsent v3|
|--|--|--|
|Use consent in framework components|Native adapters and reactive state|Browser library with framework setup recipes|
|Show preferences|Category and vendor controls|Category controls and individual service switches|
|Resolve consent in Next.js|Server, streamed and browser paths|Browser setup. Its React example starts in an effect|
|Keep remote consent records|Inth hosts the backend and stores records in its database. Self-hosting is optional|Send records to your own backend through callbacks|
|Change the interface|Themes, component parts and headless APIs|Modal options, CSS and custom content|
|Control scripts|Registered integrations, request rules and embeds|Script attributes and service callbacks|
|Clear cookies after withdrawal|Optional category rules. Vendor-only refusal needs separate cleanup|Category and service cookie cleanup|
|Use Google Consent Mode|Documented Google tag and GTM integrations|Documented Consent Mode implementation|
|Pay for software|No licence fee. Backend costs remain|No licence fee. Any record backend is your responsibility|

Sources: [setup](https://cookieconsent.orestbida.com/essential/getting-started.html), [configuration](https://cookieconsent.orestbida.com/reference/configuration-reference.html), [consent records](https://cookieconsent.orestbida.com/advanced/consent-logging.html), [script controls](https://cookieconsent.orestbida.com/advanced/manage-scripts.html) and [Google Consent Mode](https://cookieconsent.orestbida.com/advanced/google-consent-mode.html).

## Use a backend that already understands consent

CookieConsent's record guide leaves the request to your own backend. That route works, but your team must supply storage, delivery and retrieval.

c15t gives you a [backend protocol and implementation](/docs/self-host/overview). The interface can use that consent state without a separate record system designed from scratch.

Check browser state and saved records separately. c15t applies a visitor's choice locally before the backend confirms it. Failed submissions have retry and expiry limits.

See the [consent state guide](/docs/concepts/consent-state) for those conditions.

## Fit consent to the application

Your c15t preference controls and gated content can use the same framework state. Use the supplied interface or build one with [headless APIs](/docs/frameworks/react/headless).

In Next.js, you can [choose how consent resolves](/docs/frameworks/next/rendering). The App Router's default streamed path shows the page first and sends the banner in a later chunk, before hydration. An awaited path sends the page and the banner together.

CookieConsent supports service switches, cookie cleanup and framework integration. c15t's stronger case is the integrated framework and backend workflow.

## What c15t does not include

* **A production record service with no setup or cost.** Configure Inth or deploy a backend.
* **Automatic vendor discovery.** Your team still needs to register the site's scripts and embeds.
* **Service-cookie cleanup for every vendor refusal.** The built-in cleanup follows categories. A vendor-only denial needs explicit cleanup.
* **Stable status for this release.** The version covered here is alpha.

If a local browser library covers the whole job, CookieConsent can need less infrastructure.

## Test the full choice lifecycle

Choose c15t when the product needs a common model for UI, vendor behaviour and remote records. Start with [Inth and the framework guide](/docs/frameworks).

Accept one category and reject another. Reload, reopen preferences and withdraw the first choice.

Check both vendor requests and backend records with the [verification guide](/docs/guides/verify-consent). Do not treat a visible banner as proof that the integration works.

Sources checked on 6 October 2026. The release covered here is an alpha. We did not compare measured bundle size or speed.