Skip to main content
Cookie Gate
Promotional banner ad for the Penetration Testing Report Kit
Category: Consent Records

Consent String Specification

Also known as: Consent String, TC String, GPP String
Simply put

A consent string is a compact, machine-readable piece of encoded data that records a user's privacy choices, such as whether they have consented to certain uses of their data, so that this information can be passed between different systems and companies. The term also refers to the published technical specifications that define how such strings are structured and encoded, developed by industry bodies to support compliance with EU rules including the ePrivacy Directive and the GDPR. A consent string is a technical mechanism for communicating choices; it does not by itself guarantee that the underlying consent was validly obtained.

Formal definition

A Consent String Specification is a standardized format that defines how a user's disclosed information and expressed privacy choices are encoded into a compact, machine-readable string for exchange across the advertising supply chain. In the IAB Europe Transparency & Consent Framework (TCF), the 'consent string' (commonly the TC String) encodes acquired consent (or its absence) for specified purposes and vendors; the IAB Tech Lab stewards the underlying technical specifications, while the TCF is presented as an accountability tool relying on standardisation to facilitate compliance with certain provisions of the ePrivacy Directive and the GDPR. The related Global Privacy Platform (GPP) Consent String Specification generalizes this concept, encapsulating and encoding the information disclosed to a user and their choices across multiple applicable jurisdictions within a single GPP String. Note that these specifications govern the transport and encoding of consent signals only; they do not establish whether consent meets the substantive validity standards (freely given, specific, informed, and unambiguous) required under the GDPR, and adoption of a given framework has itself been subject to regulatory scrutiny. The scope of applicable legal regimes and the encoding details vary by specification version and are out of scope for this definition.

Why it matters

Consent strings are the connective tissue of the digital advertising supply chain. When a user makes privacy choices on a website or app, those choices need to travel to the many vendors and downstream systems that may process the user's data. A consent string provides a compact, machine-readable way to communicate whether consent was acquired (or refused) for specified purposes and vendors, so that participants across the chain can act on a consistent signal rather than guessing. Without a standardized format, coordinating these signals across companies would be far more error-prone.

It is important to understand what a consent string does and does not do. The IAB Europe Transparency & Consent Framework (TCF), whose technical specifications are stewarded by the IAB Tech Lab, presents itself as an accountability tool that relies on standardisation to facilitate compliance with certain provisions of the ePrivacy Directive and the GDPR. However, the specification governs only the encoding and transport of consent signals. It does not, by itself, establish that the underlying consent met the substantive validity standards under the GDPR, namely that consent be freely given, specific, informed, and unambiguous. A technically well-formed string can still record consent that was not validly obtained.

Because of this gap between technical signalling and legal validity, organisations should treat frameworks such as the TCF and the related Global Privacy Platform (GPP) as supporting tools rather than guarantees of compliance. Adoption of a given framework has itself been subject to regulatory scrutiny, and the applicable legal regimes and encoding details vary by specification version and jurisdiction. Reliance on a consent string is therefore no substitute for independent legal judgment about whether consent obligations have actually been met in a given jurisdiction.

Who it's relevant to

Privacy officers and data protection professionals
Consent strings give these professionals a machine-readable record of what choices were communicated across the supply chain, which can support accountability efforts. They should remain aware, however, that a valid-looking string does not by itself demonstrate that consent was freely given, specific, informed, and unambiguous as required under the GDPR, nor that ePrivacy obligations governing access to a device were satisfied.
Legal counsel and compliance teams
Counsel advising on the use of frameworks such as the TCF or GPP need to distinguish between technical signalling and legal validity. Because adoption of a given framework has been subject to regulatory scrutiny, and applicable regimes and requirements differ across the EU, UK, and other jurisdictions, legal judgment remains necessary; the specification supports compliance but does not guarantee it.
Web and ad-tech developers
Developers implementing consent management or integrating with the advertising supply chain work directly with the encoding rules defined by these specifications, including the TC String and the GPP String. They should note that encoding details vary by specification version and that correctly formatting a string is a separate matter from ensuring the consent it represents was properly obtained.
Marketing and vendor management teams
Teams coordinating with downstream vendors rely on consent strings to communicate whether specific purposes and vendors have user consent, particularly within the TCF and GPP. Because the GPP String is designed to encode choices across multiple applicable jurisdictions, these teams should confirm that the signals they pass align with the differing obligations of the regions in which they operate.

Inside Consent String Specification

Encoded Consent Record
A consent string is a compact, typically Base64-encoded data structure that captures a user's consent choices in a machine-readable form, allowing that information to be passed between parties such as CMPs, publishers, and vendors.
Version and Metadata
The string generally encodes technical metadata, such as a specification or policy version identifier and timestamps for when consent was created or last updated, which help parties interpret the record correctly. The exact fields depend on the framework in use.
Vendor and Purpose Signals
Within frameworks such as the IAB Transparency and Consent Framework (TCF), the string typically records which processing purposes the user has consented to (or objected to) and which vendors those choices apply to, often referencing a centrally maintained vendor and purpose list.
Legal Basis Indicators
Some frameworks distinguish, within the encoded data, between consent and other claimed legal bases such as legitimate interest for particular purposes. Whether such reliance is appropriate is a legal question governed by the GDPR and not resolved by the string format itself.
Transmission and Storage Format
The specification defines how the encoded value is structured so it can be stored (for example in a cookie or local storage) and shared across the advertising or measurement supply chain. It is a technical container and does not itself constitute the legal consent.

Common questions

Answers to the questions practitioners most commonly ask about Consent String Specification.

Does storing a valid consent string mean my organization is compliant with cookie consent law?
No. A consent string is a standardized, machine-readable record of the choices a user made and the parameters presented to them, but it is not itself proof of legal compliance. The underlying consent must still meet the applicable standard, which under the GDPR means it must be freely given, specific, informed, and unambiguous through a clear affirmative action. A consent string can help evidence and communicate what was captured, but it does not cure defects in how consent was obtained, such as pre-ticked boxes, cookie walls, or inadequate disclosures. Whether a given implementation is lawful depends on facts beyond the string itself and on the interpretation of the relevant data protection authority.
Is a consent string the same thing as consent itself, or does it replace consent logging obligations?
No, these are distinct concepts. Consent is the user's actual permission; the consent string is an encoded representation of the state of that permission and the associated disclosures, designed to be passed between parties in a technical ecosystem. Separately, controllers may face record-keeping and accountability expectations, and a consent string may form part of the evidence retained, but it is not necessarily a complete consent log on its own. Whether it satisfies any particular record-keeping expectation depends on what information it captures and on the requirements of the relevant framework and jurisdiction, which vary.
How does a consent string typically get generated and passed to downstream vendors?
In common implementations, a consent management platform (CMP) collects the user's choices through its interface, then encodes those choices and the relevant parameters into the string according to the applicable specification's format. The string is generally made available to downstream parties, for example through a shared storage location, an API, or by being appended to requests, so that vendors can read the signaled preferences before processing. The exact mechanics depend on the specification and the CMP in use, and this description is general rather than tied to any single vendor's approach.
What information is typically encoded in a consent string?
Depending on the specification, a consent string generally encodes elements such as which purposes or processing activities the user has consented to or objected to, which vendors or parties the choices apply to, and metadata about the context, such as identifiers for the version of the framework and the CMP involved. The precise fields, their meaning, and how granular the choices are vary by specification. Because formats differ, implementers should consult the specific specification they are using rather than assume a universal structure.
How should teams handle changes or new versions of a consent string specification?
Specifications may be revised over time, which can change the encoded format, the available fields, or how strings are interpreted. Implementers generally need to track version identifiers, ensure their CMP and downstream integrations support the versions they rely on, and plan for how existing captured preferences are handled when a specification changes. Because a stored string is tied to the version under which it was created, mismatches between versions can cause misinterpretation, so version awareness is an important part of implementation. The specific migration steps depend on the specification and the tools involved.
How does a consent string relate to signals like Global Privacy Control or to opt-out frameworks used under US state laws?
A consent string and a signal such as Global Privacy Control serve different roles. A consent string typically encodes a set of choices within a defined framework, often oriented toward opt-in consent as expected in many EU jurisdictions, whereas signals like Global Privacy Control are commonly used to communicate an opt-out preference relevant under certain US state privacy laws. Some ecosystems may attempt to reflect multiple regimes, but the applicable obligations differ between the EU, the UK, and individual US states, so the meaning and legal weight of an encoded preference depend on the governing framework and jurisdiction. Mapping between these approaches is a fact-specific exercise and can raise unresolved interpretive questions.

Common misconceptions

A valid consent string means consent was validly obtained.
The string is only a technical record of the choices captured by a CMP. Whether the underlying consent meets the GDPR standard of being freely given, specific, informed, and unambiguous depends on how it was collected, not on the string's format. A well-formed string can still reflect consent gathered in a non-compliant way.
Implementing a consent string specification such as the TCF guarantees compliance.
Adopting a framework and generating conformant strings supports compliance efforts but does not replace legal judgment. Data protection authorities in the EU have scrutinized aspects of such frameworks, and compliance ultimately depends on the facts of each deployment and the applicable legal regime.
A single consent string satisfies obligations across all jurisdictions.
Consent strings were largely designed around EU ePrivacy and GDPR-style opt-in expectations. Other regimes, such as certain US state privacy laws, often rely on opt-out mechanisms and signals like Global Privacy Control, so a string built for one framework may not map cleanly onto another jurisdiction's requirements.

Best practices

Treat the consent string as a record to be logged and retained alongside your broader consent record-keeping, so you can demonstrate what choices were captured, when, and under which policy version.
Confirm that the consent-collection interface generating the string reflects a valid affirmative action and avoids pre-ticked boxes, cookie walls, or implied consent, since the string only records the outcome and cannot cure a defective consent flow.
Do not treat conformance to a consent string specification as evidence of legal compliance; involve privacy and legal counsel to assess the underlying processing and legal bases separately.
Verify that vendors and downstream parties correctly interpret and honor the purposes and signals encoded in the string, and periodically audit whether actual processing matches the recorded choices.
Map how the string interacts with obligations in each jurisdiction you operate in, recognizing that EU, UK, and US state frameworks differ and that opt-out signals such as Global Privacy Control may need separate handling.
Keep implementations aligned with the current version of the applicable specification and vendor or purpose lists, and monitor evolving guidance from relevant data protection authorities.
Application Security Isn’t Optional Anymore.