What is the difference between c15t, Inth, and CookieConsent v3?

Sites that start with a simple cookie banner often need more later: consent records, policy versions, audit trails, server-side checks, and a way to prove what a user chose. CookieConsent v3 can be a good fit for small vanilla JavaScript sites, but its consent logging layer is app-owned. c15t, especially in hosted mode through Inth or with a self-hosted backend, gives teams a backend-backed path for durable consent records.

This article is legal information for engineering teams, not legal advice. Have counsel review your consent text, vendor disclosures, regional rules, and retention policy before publication or production rollout.

What this comparison covers

By the end, you can:

• Explain where CookieConsent v3 fits and where it stops.
• Compare CookieConsent v3 with c15t hosted through Inth.
• Understand why database-backed consent records matter under EU and UK accountability rules.
• Choose between browser-only consent state, app-owned logging, and a managed consent backend.

The short version

CookieConsent v3 is a lightweight client-side consent plugin. Its docs cover categories, services, cookie cleanup, script management, callbacks, revision management, and Google Consent Mode. By default, it stores the consent state in a browser cookie named cc_cookie, with an option to use localStorage instead.

CookieConsent v3 does not include built-in consent logging. Its own consent logging guide says there is “no built-in API for consent logging” and shows developers how to send consent data to their own backend with fetch.

c15t is broader. Its comparison docs describe it as an application consent platform with JavaScript, React, and Next.js support, script loading, iframe blocking, network blocking, policy packs, backend records, and app state support. In hosted mode, c15t connects to a backend for consent lifecycle management. The docs recommend Inth for a fully managed hosted setup.

The main difference is ownership of the backend layer. With CookieConsent v3, you build and maintain consent logging if you need it. With c15t hosted through Inth, or self-hosted c15t with a database adapter, the backend-backed record layer is part of the architecture.

Why consent records matter legally

For EU and UK consent-based tracking, the banner is only one part of the system. Teams also need evidence.

GDPR Recital 42 says that when processing is based on consent, the controller should be able to demonstrate that the person gave consent. The EDPB’s consent guidance repeats the standard for valid consent: freely given, specific, informed, and unambiguous through a statement or clear affirmative action.

Cookies and similar technologies add another layer. The EDPB’s guidance on Article 5(3) of the ePrivacy Directive explains that storing information on a device, or accessing information already stored there, generally needs consent unless a narrow necessity exemption applies. In the UK, PECR applies to storage and access technologies, while the UK GDPR consent standard defines what consent means.

A database is not a legal magic wand. It does not fix vague disclosures, invalid defaults, missing vendor information, or hard-to-find withdrawal controls. But durable records help with the accountability burden. They can show what the user saw, which purposes or vendors were covered, what action the user took, when the action happened, and whether the user later changed or withdrew consent.

For an engineering team, that changes the product requirement. Consent should not live only as a UI state if the organization expects to answer audits, support requests, or regulator questions.

Product comparison

How CookieConsent v3 handles logging

CookieConsent v3 exposes callbacks and API methods that let your app collect consent data. The logging page recommends logging the first consent event and later preference changes. It uses onFirstConsent and onChange, then posts selected fields to a backend endpoint.

A TypeScript version of that pattern looks like this:

type CookieConsentApi = {
  getCookie(): {
    consentId?: string;
    revision?: number;
    lastConsentTimestamp?: string;
  };
  getUserPreferences(): {
    acceptType: string;
    acceptedCategories: string[];
    rejectedCategories: string[];
  };
  run(options: {
    onFirstConsent?: () => void;
    onChange?: () => void;
  }): void;
};

declare const CookieConsent: CookieConsentApi;

async function logConsent(): Promise<void> {
  const cookie = CookieConsent.getCookie();
  const preferences = CookieConsent.getUserPreferences();

  await fetch('/api/consent-log', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      consentId: cookie.consentId,
      revision: cookie.revision,
      acceptType: preferences.acceptType,
      acceptedCategories: preferences.acceptedCategories,
      rejectedCategories: preferences.rejectedCategories,
    }),
  });
}

CookieConsent.run({
  onFirstConsent: () => {
    void logConsent();
  },
  onChange: () => {
    void logConsent();
  },
});

That approach can work. It also means your team owns the endpoint, database schema, authentication or subject matching, retention rules, audit log, retries, and reporting.

If your site only needs a front-end banner and your legal team accepts browser-only consent state, CookieConsent v3 may be enough. If you need durable records, you should plan the backend from the start.

How c15t and Inth handle backend-backed consent

c15t separates consent UI from the storage and synchronization mode. The client modes docs describe three modes:

• Hosted mode connects to a c15t backend. It is recommended for production and supports geolocation, centralized policy resolution, audit history, offline fallback, consent record storage, and compliance audit trails.
• Offline mode stores consent in the browser only. The docs warn that it cannot provide durable consent records, server-side enforcement, or automatic jurisdiction detection.
• Custom mode lets you bring your own backend handlers.

Hosted mode is the relevant c15t and Inth comparison. Inth provides the managed hosted backend path, so your app can use c15t’s frontend components while the backend remains the source of truth for consent lifecycle data.

A Next.js setup uses ConsentManagerProvider with hosted mode:

import { type ReactNode } from 'react';
import { ConsentBanner, ConsentManagerProvider } from '@c15t/nextjs';

export function ConsentManager({ children }: { children: ReactNode }) {
  return (
    <ConsentManagerProvider
      options={{
        mode: 'hosted',
        backendURL: '/api/c15t',
      }}
    >
      <ConsentBanner />
      {children}
    </ConsentManagerProvider>
  );
}

For self-hosted deployments, c15t’s database setup docs say the backend requires a database for consent records, subjects, audit logs, and policies. Supported adapters include Kysely, Drizzle, Prisma, TypeORM, and MongoDB. The schema includes append-only consent records and an immutable audit log.

A self-hosted Prisma adapter setup looks like this:

import { c15tInstance } from '@c15t/backend';
import { prismaAdapter } from '@c15t/backend/db/adapters/prisma';
import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient();

export const c15t = c15tInstance({
  adapter: prismaAdapter(prisma),
  trustedOrigins: ['https://example.com'],
});

That database-backed design matters when product, support, legal, and security teams need to answer questions such as:

• Which consent policy version applied when the user made a choice?
• Which categories or purposes did the user accept or reject?
• Did the user later change preferences or withdraw consent?
• Can the server avoid consent-dependent behavior before the frontend finishes loading?
• Can the organization produce evidence if challenged?

When to choose each option

Choose CookieConsent v3 when you have a small static or vanilla JavaScript site, want a lightweight banner, and are prepared to build backend logging yourself if you need audit records. It gives you a clean client-side consent UI, category handling, script management, revision handling, and callbacks.

Choose c15t offline mode only when browser-only state is acceptable. It can fit local development, demos, static deployments, or controlled fallback scenarios. The c15t docs are clear about the trade-off: offline mode has no server-side consent records, no audit trail, and no centralized visibility by default.

Choose c15t hosted through Inth when consent needs to behave like application infrastructure. This is the better fit when you need durable records, jurisdiction-aware behavior, server-side visibility, audit history, and a path from a simple banner to more complex consent requirements.

Choose self-hosted c15t when you want c15t’s backend model but need to run it in your own infrastructure. You still get a database-backed design, but your team owns hosting, operations, security, backups, and database maintenance.

What a consent database should preserve

The exact schema depends on your legal basis, jurisdictions, product, and retention rules. In most serious EU or UK consent setups, the record should be able to answer these questions:

• Who or what made the choice, using an account, subject, device, or consent identifier where appropriate?
• When did the choice happen?
• Which country, region, or policy applied?
• Which purposes, categories, vendors, or services were presented?
• Which notice text or policy version did the user see?
• What action did the user take, such as accept all, reject all, save preferences, or withdraw?
• What changed later?
• Which app surface captured the choice?

CookieConsent v3 can send some of this data to your backend through callbacks. c15t’s backend-backed modes are designed around storing and synchronizing consent lifecycle data from the start.

Sources

• c15t vs CookieConsent v3
• c15t client modes
• c15t database setup
• CookieConsent v3 consent logging
• CookieConsent v3 configuration reference
• GDPR text, including Recital 42
• EDPB Guidelines 05/2020 on consent under GDPR
• EDPB Guidelines 2/2023 on Article 5(3) of the ePrivacy Directive
• ICO guidance on cookies and similar technologies
• ICO guidance on managing consent in practice

What to do next

You now have a practical way to compare the tools:

• CookieConsent v3 is a client-side banner plugin with app-owned logging.
• c15t hosted through Inth supports backend-backed consent lifecycle management.
• c15t self-hosted gives you database-backed records in your own infrastructure.
• Browser-only storage is not the same as durable proof of consent.

If you are migrating from CookieConsent v3, start by mapping your existing categories, services, revision values, and callbacks. Then decide whether you need Inth-hosted c15t, self-hosted c15t, or a custom backend mode. Ask legal counsel to confirm what records you need to retain and how long to keep them.