Category: Legal Basis and Consent

Consent String

Also known as: daisybit, TCF String, TC String

Simply put

A consent string is a compact, machine-readable code that captures the privacy and consent choices a user has made, so that those choices can be passed between different systems. In online advertising, it commonly travels alongside an ad request to indicate whether a user has agreed to particular uses of their data. It is a technical carrier of a consent signal rather than proof that valid consent was obtained.

Formal definition

A consent string is an encoded, machine-readable data structure that represents a user's privacy choices, including consent status and, in some frameworks, publisher transparency information, and is exchanged between participating systems (for example, added to an ad bid request). The most widely referenced example is the string defined under IAB Europe's Transparency & Consent Framework (TCF), which IAB Europe describes as an accountability tool built on standardisation to facilitate compliance with certain provisions of the ePrivacy Directive and the EU GDPR. A consent string encodes the recorded outcome of a consent interaction; it does not by itself establish that consent met the validity conditions of any applicable law, nor does it determine the lawful basis for processing, which may or may not be consent. Treatment and applicability differ across jurisdictions and regimes; this entry does not cover the mechanics of consent capture, the technical encoding format and version specifics, string length or URL constraints, storage and retention, or enforcement. Practitioners should validate any specific claims against the relevant framework specification and applicable law.

Why it matters

A consent string matters because modern digital advertising and content delivery involve many participating systems that never interact directly with the user. The consent string provides a compact, machine-readable way to carry a user's recorded privacy choices between these systems, so that a signal reflecting those choices can travel alongside an ad bid request or similar transaction. Without such a standardised carrier, downstream parties would have no consistent means of learning what a user was told or what they indicated.

The critical point for practitioners is that a consent string is a technical carrier of a signal, not proof that valid consent was obtained. It encodes the recorded outcome of a consent interaction, but it does not by itself establish that the consent met the validity conditions of any applicable law, and it does not determine the lawful basis for processing, which may or may not be consent. Under the EU GDPR and the ePrivacy Directive, consent is only one of several possible lawful bases, and treating the presence of a consent string as equivalent to demonstrable, valid consent is a common and consequential error. IAB Europe describes its Transparency & Consent Framework (TCF), which defines the most widely referenced consent string, as an accountability tool built on standardisation to facilitate compliance with certain provisions of the ePrivacy Directive and the GDPR, framing it as an aid to compliance rather than a guarantee of it.

Accountability under governance and data protection frameworks generally requires demonstrable evidence that consent was validly captured, not merely the existence of an encoded string asserting a status. Organisations relying on consent strings should therefore treat them as one component within a broader consent capture and record-keeping process, and validate any specific claims against the relevant framework specification and applicable law.

Who it's relevant to

Data Protection Officers and Privacy Counsel

DPOs and privacy legal teams need to understand that a consent string reflects a recorded signal, not validated consent, and that it does not establish the lawful basis for processing. Where consent is the chosen lawful basis under the EU GDPR or ePrivacy Directive, they should ensure the underlying capture process meets the applicable validity conditions and that demonstrable evidence exists, since the string alone does not satisfy accountability requirements. Treatment differs across jurisdictions, so claims should be checked against applicable law.

AdTech and Privacy Engineers

Engineers implementing or consuming consent strings, for example within the TCF, are responsible for correctly generating, transmitting, and parsing the encoded structure so that recorded choices are passed accurately between systems. They should treat the string as a technical carrier within a larger consent management architecture and refer to the relevant framework specification for encoding format, version specifics, and constraints not covered here.

Publishers and Advertising Operations Teams

Publishers relying on frameworks such as IAB Europe's TCF use consent strings, which may carry publisher transparency information, to communicate user choices to advertising partners. Operations teams should understand that the framework is described by IAB Europe as an accountability tool to facilitate compliance rather than a guarantee of it, and that presence of a string is not a substitute for a sound consent capture and record-keeping process.

Information Governance and Compliance Leads

Governance leads coordinating consent management across systems should recognise the boundary between the technical signal a consent string carries and the governance evidence needed to demonstrate valid consent. This entry does not address storage, retention, or enforcement, so those obligations must be managed separately within the organisation's broader governance and record-keeping framework.

Inside Consent String

Encoded Consent Signals

A consent string is a compact, machine-readable encoding that captures a user's choices regarding data processing, typically expressing which purposes and which parties (vendors) the user has permitted or objected to.

Purpose and Legal Basis Indicators

The string generally records the processing purposes the user consented to, and in some frameworks distinguishes purposes relying on consent from those asserted under other lawful bases such as legitimate interests. Note that consent is only one of several lawful bases and the string's presence does not by itself establish that a valid lawful basis exists.

Vendor or Party Scope

It typically identifies the specific third parties or vendors to whom the recorded preferences apply, often by reference to a registered list rather than by naming each party inline.

Framework and Version Metadata

The string usually carries metadata identifying the framework specification and version under which it was generated, so downstream parties can interpret the encoding correctly.

Timestamps

Consent strings commonly include creation and last-updated timestamps to support demonstrating when a choice was made or changed, which is relevant to accountability but is not on its own a complete audit record.

Identifier or Reference Data

The string may reference the entity that captured consent and, in some cases, values that can relate to an individual or device. Because it can be linked to a person, a consent string is generally itself personal data and remains in scope of applicable data protection rules.

Common questions

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

Does a valid consent string on its own establish a lawful basis for processing?

No. A consent string is a technical record that encodes consent choices; it does not by itself guarantee that consent was validly obtained. Under regimes such as the EU GDPR, consent must generally be freely given, specific, informed, and unambiguous, and the string is only evidence of a choice made through a particular interface. If the underlying consent flow is defective, the string does not cure it. In addition, consent is only one of several lawful bases, and a string reflecting consent has no bearing on processing that relies on a different basis.

Does encoding or storing consent in a compact string make the associated data non-personal?

No. A consent string typically links to or is associated with an identifier and reflects processing choices about an individual, so the string and the data it governs generally remain personal data. Encoding, hashing, or compressing the string does not anonymize it, and reversible techniques such as pseudonymization still leave the data in scope. The format of the record does not change the regulatory status of the personal data being processed.

How should a consent string be stored and associated with a data subject for later use?

A consent string is generally stored alongside contextual metadata needed to demonstrate accountability, such as the version of the notice or purposes presented, a timestamp, and the interface or mechanism used. It is typically associated with an identifier for the individual or session so downstream systems can check the recorded choices before processing. This entry does not cover retention periods for consent records, which depend on jurisdiction, purpose, and evidentiary needs.

How is a consent string interpreted by downstream systems before processing occurs?

Downstream systems generally decode the string according to the specification or schema that produced it, then evaluate whether the specific purpose they intend to pursue is permitted by the recorded choices. Correct interpretation depends on both parties using the same version of the encoding and purpose taxonomy. This entry does not address the mechanics of any particular industry framework or its signalling conventions.

What should happen to a consent string when a data subject changes or withdraws their choices?

When choices change, a new consent string generally reflects the updated state and supersedes the prior record, while the earlier record is typically retained as evidence of what was in effect at a given time. Withdrawal of consent should be as easy as giving it in most jurisdictions, and systems relying on the string should stop the affected processing accordingly. This entry does not cover the downstream deletion or restriction obligations that may follow a withdrawal.

How does a consent string support demonstrable accountability?

Accountability under most governance frameworks requires demonstrable evidence rather than stated intent, and a consent string can form part of that evidence by recording what an individual chose and, with accompanying metadata, the conditions under which the choice was made. On its own it is generally insufficient; it typically needs to be paired with records of the notice presented, the mechanism used, and the version of purposes, and to be reconcilable with actual processing behavior. This entry does not address broader records of processing obligations, which are distinct from consent records.

Common misconceptions

A stored consent string proves compliance with data protection law.

A consent string is a record of a signal, not a guarantee of compliance. In most jurisdictions, valid consent must meet substantive conditions (for example, being freely given, specific, informed, and revocable), and consent is only one of several lawful bases. Whether processing is lawful depends on context, jurisdiction, and implementation, not on the mere existence of a string. This entry does not address enforcement or the full validity criteria for consent.

A consent string is anonymous technical data and therefore out of scope of privacy regulation.

Because a consent string can typically be linked to an individual or device and often carries identifiers or references, it is generally treated as personal data. Encoding or compressing the data does not make it non-personal, just as encryption or tokenization does not remove data from scope.

The consent string is interchangeable across frameworks and jurisdictions.

Consent strings are defined by specific framework specifications and versions, and their meaning depends on the framework used. Treatment of consent and lawful bases differs across regimes such as the EU GDPR, the UK GDPR, and the CCPA and CPRA, so a string valid under one framework should not be assumed to satisfy requirements elsewhere.

Best practices

Record and retain the framework identifier, version, and timestamps alongside each consent string so choices can be interpreted correctly and demonstrated later, recognizing that accountability requires demonstrable evidence rather than stated intent.

Treat consent strings as personal data and apply appropriate access, retention, and security controls, without assuming that encoding, encryption, or tokenization removes them from regulatory scope.

Do not rely on a consent string as sole proof of a valid lawful basis; confirm that the underlying consent (or alternative lawful basis) meets the substantive requirements of each applicable jurisdiction.

Map which processing purposes and which parties each string covers, and ensure downstream systems and vendors honor and do not exceed the recorded scope.

Provide and honor mechanisms for individuals to withdraw or change consent, ensuring updated strings propagate to relevant parties, since consent is generally revocable.

Validate strings against the correct framework specification and version before acting on them, and avoid assuming a string generated under one framework applies to another regime.