---
title: c15t vs react-cookie-consent
description: Choose c15t when a React application needs consent rules, vendor
  controls and backend records beyond an accept-and-decline banner.
group: reference
lastModified: "2026-10-10T16:01:45+01:00"
---
## Choose c15t when consent controls product behaviour

c15t is the stronger fit when consent determines which vendors and features can run. It combines the banner, preferences, policy state and vendor integrations with a record backend.

react-cookie-consent gives you a customisable React bar, cookie helpers and callbacks. It is a useful small component when your application already owns the rest of the consent system.

## 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 your team must build

|What you need|c15t|react-cookie-consent|
|--|--|--|
|Show a consent banner|Policy-aware framework components|Configurable React bar|
|Offer category and vendor preferences|Built-in controls|Build the rest of the preference flow|
|Decide whether a feature can run|Effective permissions and vendor state|Connect callbacks and the cookie value to your own rules|
|Control vendor scripts|Registered integrations and consent rules|Build the loader behaviour around callbacks|
|Keep remote records|Inth hosts the backend and stores records in its database. Self-hosting is optional|Build a backend integration|
|Handle policy changes|Policy resolution and recorded choices|Supply your own policy logic|
|Reopen preferences|Preference dialog and persistent access|Visibility and cookie-reset helpers|
|Customise presentation|Themes, component parts or headless UI|Styles, classes, content and button props|

Sources: [README](https://github.com/Mastermindzh/react-cookie-consent) and [npm package](https://www.npmjs.com/package/react-cookie-consent).

Custom application code can extend the component. Those extensions are work that the component itself does not supply.

## Connect the choice to the vendor

With c15t, your team can read whether a feature can run from the same state that drives the consent interface. Register analytics or embeds through [c15t integrations](/docs/integrations/overview).

This gives the application a shared model for first visits, saved choices and later withdrawal. You still need to remove unconditional loaders.

A callback that starts analytics after acceptance also needs to handle rejection, reload and withdrawal. c15t supplies those integration points as part of its consent runtime.

## Keep permission separate from a recorded choice

c15t distinguishes the permissions allowed by a policy from what the visitor explicitly chose. Your application can read both without a false record of consent.

That distinction matters for regional policies, stored choices and privacy signals. See the [consent model](/docs/concepts/how-consent-works).

The backend can store confirmed choices. Browser state changes first, so check the actual record after a save. A failed request is not a completed record.

## What c15t does not include

* **Setup as small as a standalone bar.** Production policy and records need an Inth connection or your own backend.
* **Automatic control of current analytics code.** Move it from old callbacks into registered integrations or explicit rules.
* **A safe automatic conversion of a boolean cookie.** Review what visitors previously accepted before you create category or vendor grants.
* **Legal-policy generation or a website scanner.** These are outside the c15t packages.

If you only need a bar and already have the other consent infrastructure, react-cookie-consent can be enough.

## Replace one acceptance callback first

Choose c15t when you want the consent infrastructure as well as the React interface. Follow the [React quickstart](/docs/frameworks/react/quickstart) with [Inth](https://inth.com).

For a Next.js application, use its [router guide](/docs/frameworks/next/quickstart). Find the old `onAccept` loader, register its c15t replacement and remove the duplicate.

Test a fresh visit and a visitor who previously rejected consent. Finish with the [verification guide](/docs/guides/verify-consent).

Sources checked on 6 October 2026. The release covered here is an alpha. The comparison covers the published component, not every system that someone could build around it.