Skip to main content
Cookie Gate
Commerce Security logo, "All 12 PCI DSS Requirements in Plain English," "Get it now for free," "Complete Survival Guide" and a button toclick to get it
Category: Consent Records

GPP String

Also known as: GPP, Global Privacy Platform String, GPP Consent String
Simply put

A GPP String is a compact, machine-readable code that records a user's privacy and consent choices and passes them from websites or apps to advertising technology providers. It is designed to carry those preferences across multiple jurisdictions in a single string rather than using a separate signal for each region. It is a technical mechanism for communicating choices, not itself a legal guarantee that any given consent is valid under a particular law.

Formal definition

The GPP (Global Privacy Platform) String is a standardized, encoded format defined by the IAB Tech Lab that encapsulates disclosures made to a user and the user's expressed privacy and consent choices for all applicable jurisdictions. According to its specification, it concatenates jurisdiction-specific sections into a single string, enabling the transmission of privacy, consent, and consumer-choice signals from sites and apps to ad tech providers across different regulatory frameworks. The GPP String functions as a transport and encoding layer for signals; the substantive legality of the underlying consent or opt-out still depends on the applicable regime (for example, opt-in standards common in the EU versus opt-out approaches common under US state laws), and the specifics of which jurisdictional sections and encodings are supported are governed by the GPP specification rather than by this definition. Use of the GPP String supports interoperability and compliance workflows but does not by itself establish that consent is freely given, specific, informed, and unambiguous, nor that any particular jurisdiction's requirements have been met.

Why it matters

As privacy laws proliferate across the EU, the UK, and individual US states, the advertising ecosystem faces the challenge of communicating a single user's choices across multiple regulatory frameworks simultaneously. Before consolidated signaling approaches, sites and apps often needed separate mechanisms for each region, increasing complexity and the risk of inconsistent or dropped signals as data moved between publishers and ad tech providers. The GPP String matters because it offers a standardized, machine-readable way to carry disclosures and consent or opt-out choices from sites and apps to ad tech vendors in a single string, supporting interoperability across jurisdictions.

For compliance teams, the practical significance is that the GPP String can reduce the operational friction of honoring different requirements in different markets, for example, the opt-in standards common in the EU versus the opt-out approaches common under US state laws, by encapsulating jurisdiction-specific sections in one transport layer. This can help ensure that a user's expressed preferences travel with a bid request or data exchange rather than being lost or reinterpreted downstream.

At the same time, it is important not to overstate what the GPP String accomplishes. It is a mechanism for encoding and transmitting signals, not a legal guarantee. The substantive validity of any consent or opt-out still depends on the applicable regime and on whether the underlying interaction met that regime's standards, such as consent being freely given, specific, informed, and unambiguous under the GDPR. A correctly formatted GPP String does not, by itself, establish that any jurisdiction's requirements have been satisfied.

Who it's relevant to

Publishers and website operators
Sites and apps that participate in the advertising ecosystem may use the GPP String to communicate user privacy and consent choices to ad tech providers. It can help publishers pass consistent signals across multiple jurisdictions from a single string, though it does not remove the underlying obligation to obtain valid consent or honor opt-outs under the applicable regime.
Ad tech vendors and advertisers
Advertisers, technology vendors, and other ad tech providers are the intended recipients of GPP Strings, which enable them to adapt to regulatory requirements across markets by reading the encoded preferences. They still need to interpret and act on those signals appropriately for each jurisdiction, since the string itself does not determine legality.
Privacy and compliance teams
Privacy officers, data protection professionals, and legal counsel evaluating cross-jurisdictional consent workflows should understand that the GPP String supports interoperability and compliance processes but does not by itself establish that consent is freely given, specific, informed, and unambiguous, nor that any particular jurisdiction's requirements have been met. It is one component of a broader compliance program, not a substitute for legal judgment.
Developers and CMP implementers
Web and app developers and those building or integrating consent management platforms work directly with the GPP specification defined by the IAB Tech Lab to generate, encode, and transmit the string. Because the supported jurisdictional sections and encodings are governed by that specification, implementers should reference the current specification rather than relying on assumptions about which regions or formats are covered.

Inside GPP

Global Privacy Platform (GPP) framework
The GPP is a protocol developed by the IAB Tech Lab intended to standardize the transmission of privacy and consent signals across multiple jurisdictions and regulatory frameworks. The GPP String is the encoded output of this framework, designed to be passed between parties in the digital advertising supply chain.
Section identifiers
A GPP String can carry multiple jurisdiction- or framework-specific sections within a single encoded string. Each section corresponds to a particular regime or specification, allowing signals for different geographies to coexist in one structure rather than requiring separate strings.
Header and encoding
The string includes a header component that indicates which sections are present and how the payload is structured. The overall value is encoded so that it can be efficiently stored and transmitted, and decoded by parties that support the specification.
Framework-specific consent and preference signals
Within its sections, a GPP String may convey consent, opt-out, or preference information reflecting the requirements of the applicable regime. The precise meaning of any given signal depends on the section and the framework it represents, not on the GPP container itself.
Relationship to the TCF and US signals
The GPP is intended to accommodate signals such as those from the IAB Transparency and Consent Framework (TCF), which is commonly associated with EU and UK opt-in consent, alongside signals designed for US state privacy contexts that often rely on opt-out mechanisms. The GPP String acts as a transport layer for these distinct signals.

Common questions

Answers to the questions practitioners most commonly ask about GPP.

Does a GPP String on its own make my site compliant with cookie and privacy laws?
No. The GPP String is a technical encoding that transports consent and preference signals in a standardized, portable format across jurisdictions and frameworks. It supports compliance by communicating user choices between parties, but it does not by itself establish that valid consent was obtained, that notices were adequate, or that processing is lawful. Compliance depends on how consent is collected, disclosed, and honored, and on the legal requirements of the applicable regime, which may differ across the EU, UK, and individual US states. The string reflects choices; it does not substitute for the legal judgment behind them.
Is the GPP String just another name for the IAB TCF consent string?
No, though they are related. The TCF string encodes signals for the IAB Transparency and Consent Framework, which is primarily oriented toward EU-style consent for digital advertising. The GPP (Global Privacy Platform) String is a broader, multi-jurisdiction container designed to carry signals for several different frameworks and sections, potentially including US state signals and other regional formats, within a single standardized structure. A GPP String may contain a TCF-related section alongside others, but the two are not interchangeable, and using one does not automatically satisfy the requirements associated with the other.
How does a GPP String typically get generated and made available to downstream parties?
In most implementations, a consent management platform (CMP) collects the user's choices and encodes them into the GPP String, which is then exposed to other parties through the associated API and, in some setups, passed within advertising or data-sharing requests. The exact retrieval method depends on the platform and integration, so teams should confirm how their specific CMP surfaces the string and which sections it populates.
Which sections of a GPP String should I populate for my audience?
The sections you populate generally depend on where your users are located and which frameworks apply to them. A single GPP String can carry multiple jurisdiction-specific sections, so an implementation serving both EU and US-state audiences may need to encode different sections for different users or contexts. Determining which sections are required is a legal and factual question tied to the applicable regimes, and should be confirmed with your privacy and legal teams rather than assumed from the technical capability alone.
How do we make sure downstream vendors actually read and honor the GPP String?
Encoding the string is only part of the process; the signals it carries must be received and acted upon by the parties that process the data. In practice this typically involves confirming that vendors and partners support the GPP API and the relevant sections, testing that signals are transmitted correctly, and addressing honoring of choices through contractual and technical arrangements. The standard defines how signals are structured and transported, but it does not guarantee that any given recipient will interpret or respect them, so verification and record-keeping remain important.
Should we keep records of the GPP Strings we generate?
Maintaining records that evidence the choices users made can support consent logging and record-keeping objectives, which are relevant under several privacy regimes. Whether the encoded string alone is sufficient evidence, and what additional context should be retained, depends on the applicable legal requirements and the interpretation of the relevant authorities. Teams should treat the string as one element of a broader record-keeping approach and confirm retention practices with their compliance function rather than relying on the string as a complete audit trail.

Common misconceptions

A valid GPP String means a website is compliant with applicable privacy laws.
The GPP String is a technical mechanism for encoding and transmitting privacy signals; it does not by itself establish that valid consent was obtained or that opt-out rights were honored. Compliance depends on how consent or preferences were actually collected and processed under the relevant regime, and tools of this kind support compliance efforts but do not replace legal judgment.
One GPP String applies the same consent rules everywhere.
The GPP is designed to carry multiple jurisdiction-specific sections precisely because obligations differ between the EU, the UK, and individual US states such as California. A signal appropriate for an opt-out regime should not be treated as satisfying the opt-in consent standards generally required in most EU jurisdictions, and vice versa.
The GPP String replaces the TCF or other existing frameworks.
The GPP is intended to act as a container that can transport signals from frameworks such as the TCF as well as US-focused signals, rather than superseding them. The underlying framework rules still govern what a given signal means and when it is validly generated.

Best practices

Treat the GPP String as a transport mechanism only, and verify separately that the consent or opt-out signals it carries were collected through processes that meet the standards of each applicable regime.
Confirm that the correct jurisdiction-specific section is populated for each user based on their location and the applicable framework, rather than relying on a single generic signal across all geographies.
Ensure that vendors and downstream partners in the supply chain actually support decoding and honoring the specific GPP sections you transmit, since an unread signal provides no practical protection.
Maintain your own consent and preference records independently of the GPP String, so that record-keeping and demonstrability obligations do not depend solely on a signal passed to third parties.
Coordinate GPP implementation with your consent management platform (CMP) configuration and keep both aligned as framework specifications and regulatory guidance evolve.
Seek legal review of how GPP signals map to your obligations in the EU, the UK, and relevant US states, given that enforcement positions and framework interpretations may change over time.
Application Security Isn’t Optional Anymore.