Where is the TC string stored?

Most CMPs persist the TC string in a first-party cookie named euconsent-v2, and expose it to scripts on the page through the __tcfapi JavaScript function defined by the TCF specification.

Is a TC string personal data?

The string itself encodes choices, not identity, but regulators treat it as linked to the user it belongs to - the Belgian DPA's IAB Europe decision considered TC strings personal data in context. Handle them like any other consent record.

How long is a TC string valid?

TCF policy requires CMPs to re-establish consent periodically - in practice CMPs refresh the string at least every 13 months, and platforms may reject strings whose lastUpdated timestamp is too old or inconsistent.

Can I decode a TC string without any tools?

Technically yes - the format is a documented bit-level encoding - but nobody decodes them by hand. A decoder such as the free Kukie.io TCF String Decoder shows purposes, vendors, and restrictions instantly.

What Is a TC String? TCF Consent Strings Explained

A TC string (Transparency and Consent string) is a compact, Base64-encoded record of the consent choices a visitor made in a TCF-registered consent banner. It captures which data-processing purposes the visitor accepted, which vendors may act on them, and which legal bases apply - all in a single machine-readable value that adtech systems pass along the advertising chain. If you have ever seen a value starting with CP stored in a cookie called euconsent-v2, that is a TC string.

Why TC strings exist

Under the GDPR and the ePrivacy Directive, every party that processes personal data for advertising needs a legal basis - and in the EU that is almost always consent collected on the publisher's website. The problem: a single ad impression can involve dozens of vendors (SSPs, DSPs, measurement providers), none of which have any direct relationship with the visitor.

IAB Europe's Transparency and Consent Framework (TCF) solves the relay problem: the consent management platform (CMP) collects the choices once, encodes them into a TC string, and every downstream vendor decodes the same string to check whether it is allowed to process the data. No string, or an invalid string, and TCF-enforcing platforms treat the request as no-consent.

What is inside a TC string

A TC string is not encrypted - it is an efficient bit-level encoding that anyone can decode. The core segment contains:

Metadata: TCF version, creation and last-updated timestamps, the ID and version of the CMP that created it, and the language shown to the user.
Purpose consents: one bit per standardised purpose (storing information on a device, personalised advertising, measurement, and so on).
Purpose legitimate interests: which purposes are claimed under legitimate interest. Since TCF v2.2, advertising purposes can no longer rely on legitimate interest at all.
Vendor consents: one bit per vendor ID from the Global Vendor List, marking which registered vendors received consent.
Publisher restrictions: purpose-level limits the publisher imposed on specific vendors.

Additional segments can follow the core: a disclosedVendors segment recording which vendors were actually shown to the user (mandatory in TC strings created under TCF v2.3), and a publisher purposes segment for the site's own processing.

A worked example

Take a string beginning CPz4Yc APz4YcAAGXkDENDbCsAP_AAH_AAAqIK7 (shortened here). The first characters already tell a decoder a lot: the leading C family marks the TCF v2 format, and the next characters encode the creation timestamp, the CMP ID and CMP version, and the consent screen and language the visitor saw. Everything after that is bit fields: purpose consents come first (a visitor who accepted analytics-style measurement but refused personalised advertising produces a distinctive on-off pattern here), then legitimate-interest flags, then the vendor bitfield, where the bit at position 755 answers the single most consequential question for most publishers - did Google Advertising Products receive consent?

Reading bit offsets by eye is nobody's job. The point of the example is that every claim your consent banner makes has a verifiable, decodable representation - which is exactly what auditors, ad partners, and debugging sessions rely on.

Versions: from v2.0 to v2.3

The TC string format has been stable since TCF v2.0 (2020), but the policy around it keeps tightening. TCF v2.2 (May 2023) removed legitimate interest as a legal basis for advertising purposes and expanded the storage disclosures vendors must publish, which changed what CMPs must show before a string is created. TCF v2.3 (released 19 June 2025, mandatory from 1 March 2026) made the disclosedVendors segment compulsory, so the string now proves not just what was consented but which vendors were actually surfaced to the visitor. Strings that predate a policy change do not need to be regenerated retroactively, but new strings must follow the current rules - which is why platform-side validation errors cluster around transition deadlines.

TC strings as consent records

Because the string is a self-contained, timestamped record of exactly what the visitor was shown and what they chose, it doubles as audit evidence. GDPR Article 7(1) puts the burden of demonstrating consent on the controller, and in the TCF ecosystem the TC string is the artefact that carries that proof through the supply chain. Publishers should retain the strings their CMP issues alongside their regular processing records retention approach, and be able to decode any stored string on request.

Who creates and who reads it

Only a CMP registered with IAB Europe (each has a numeric CMP ID) may create TC strings. The string is then exposed on the page through the __tcfapi JavaScript function, which ad tags and SDKs call to read consent before firing. It also typically persists in the euconsent-v2 cookie so the choice survives page loads.

Readers include ad servers such as Google Ad Manager, SSPs and DSPs in real-time bidding, and measurement vendors. Google additionally consumes an AC string for vendors outside the TCF - see our guide to Google Additional Consent.

How to decode a TC string

Because the format is public, decoding is safe and instant. Paste any TC string into our free TCF String Decoder and you will see the TCF version, CMP ID, purpose-by-purpose consent and legitimate-interest flags, vendor consent lists, and publisher restrictions - useful for verifying that your banner records what you think it records.

Decoding is also the first step when a platform rejects your consent signals: our guide to common TC string errors walks through the failure modes, from expired strings to a missing disclosedVendors segment.

TC strings and Google Consent Mode are not the same thing

A TC string is a vendor-by-vendor consent record for the TCF ecosystem. Google Consent Mode v2 is a separate, simpler signal (granted or denied per consent type) that Google's own tags consume. Publishers monetising with Google ad products in the EEA generally need TCF; most business websites running analytics and marketing tags need Consent Mode. Our comparison of who actually needs TCF covers the decision in detail.

Do regular business websites need TC strings?

Usually not. If your site does not sell programmatic display advertising, a standard consent banner with per-category choices and Google Consent Mode v2 covers analytics and marketing tags without TCF registration. TC strings become relevant when you monetise with AdSense, Ad Manager or header bidding - the ecosystems that enforce the framework. If you are unsure what your site actually loads, start with a free cookie scan and see which vendors appear.