GPP consent string decoder: read every section of a Global Privacy Protocol string

Paste the string from the regs.gpp field of a bid request, from a gpp URL parameter, or from your consent management platform. Add the gpp_sid value if you have it, and the decoder marks which section applies to the transaction.

1. Paste the string. A GPP string starts with D and separates sections with ~. If you paste a TC String (it starts with C), the decoder sends you to the TCF consent string decoder.
2. Add gpp_sid if you have it. It is the list of section IDs in force for this transaction, for example 7 or 2.
3. Read the header card. It lists the sections the string declares, in order, and checks that each one has a payload.
4. Open a section. Each panel shows every field, its raw value and its meaning, and a badge for the section version.
5. Copy or share. Copy the decoded JSON, or a link that keeps the string in the URL fragment so it never reaches our server.

You can also paste a single section, such as BVWSSSVY.YA, and pick its section ID. That helps when a log stores sections separately.

A GPP string is a header plus one payload per section, joined by tildes. The header holds a type of 3, a version of 1, and the list of section IDs. It encodes that list with Fibonacci coding, which writes small numbers in few bits and needs no length prefix (GPP Consent String Specification).

The first character tells you what you are holding. A D means a GPP string, because the header type 3 encodes as D. A C means a bare TCF consent string, because its version 2 encodes as C.

Each section is decoded by its own rules (Section Information). The EU TCF section is the TC String itself. The US sections use two-bit fields, so each value is 0, 1, 2 or, in error, 3. Optional subsections follow a dot; in most US sections the only one is Global Privacy Control (GPC).

Sources for the table: Section Information and the section files linked from it.

The same digit means different things in different fields. This is the most common reason people misread a decoded US section, so the decoder always prints the meaning next to the number.

Read the third row twice. A 1 in a consent field means the user did not consent. A 1 in an opt-out field means the user did opt out. Both are restrictive, but for different reasons (US National specification, version 2 text, June 2026).

The US National section lists 16 sensitive data categories in version 2, up from 12 in version 1. They run from racial or ethnic origin and religious beliefs to consumer health data, crime victim status, national origin and transgender or nonbinary status. Known-child consents grew from two age bands to three. Which states treat which data as sensitive is tracked in the state health privacy laws tracker.

The US National section version 3 is short. Its core holds MspaVersion, MspaNotice, MspaOptOut and a 14-bit MspaId, the identifier of the first party that signed the agreement. The GPC subsection must always be present. The notice, opt-out and sensitive-data fields of versions 1 and 2 are gone (US National specification).

State sections did not change layout. They now tell implementers to stop using the MSPA fields and to set them to fixed values. IAB Tech Lab described the package as removing MSPA coverage for the state-by-state approach, ending Service Provider and Opt-Out Option modes, and simplifying notice and choice fields (IAB Tech Lab, 11 August 2026).

What this means for decoding is simple: version 1 and 2 strings will keep arriving for months. The decoder reads all three US National versions, tells you which one it found, and adds a note when a state section still carries MSPA values that the new text retires. On 9 November 2026 IAB Tech Lab's own GPP page still described the update as in public comment (IAB Tech Lab GPP page, updated 12 August 2026). Check that page for the final release before you change production logic.

Section 2 carries the IAB Europe TC String unchanged. The GPP extension says the encoded section "is expected to be exactly the same" as a standalone TC String, and that the TCF specification wins on any discrepancy (GPP extension for IAB Europe TCF). That matters because the extension still calls the Disclosed Vendors segment optional, while TCF 2.3 made it mandatory. The decoder applies the TCF 2.3 rule, as the TCF consent string decoder does.

Section 5 carries the IAB Canada TCF. It mirrors the European structure with Canadian terms: express consent instead of consent, implied consent instead of legitimate interest (GPP extension for IAB Canada TCF). Its vendor lists use Fibonacci ranges. The IAB Tech Lab reference library notes that an earlier version of its own encoder wrote fixed-integer ranges, and it decodes both by checking which reading re-encodes to the same bits (iabgpp-es TcfCaV1 tests). The decoder uses the same check and tells you when it fell back to the legacy reading.

This string comes from the IAB Tech Lab reference library's tests (iabgpp-es, GppModel tests):

In plain words, the publisher declares an MSPA covered transaction and records no consent for sensitive data or children's data. A buyer reading only the opt-out fields would see nothing restrictive. A buyer that also reads the consent fields would exclude every sensitive-data audience. Under the November 2026 text, a fresh version 3 string from the same publisher would carry neither set of fields, only the MSPA notice, opt-out and signatory ID.

The third row is worth a minute. The specification's own example declares sections 5 and 6, but the payload after the header is the European TC String from example 1. A strict decoder reads a version number of 2 where the Canadian section expects 1 and reports the section as undecodable, while still decoding the US Privacy section. The decoder does exactly that.

The decoder reports signals, not legal conclusions. How a buyer should act on each signal in a bid request is covered in GPP and TCF implementation for engineers, and where the fields sit in a request in OpenRTB 2.6 explained. The broader hub is identity and privacy.

The decoder follows the GPP specification files in the IAB Tech Lab repository at the commit of 4 November 2026. Each section has a schema transcribed from its specification file, and a test in our build fails if a schema drifts from the official test strings. The decoder keeps older section versions so that strings written before November 2026 still decode.

It does not check whether a consent management platform showed the right notice, whether a company is really an MSPA signatory, or whether a state law applies to a user. The MspaId in US National version 3 is shown as a number; matching it to a signatory requires the MSPA signatory list, which the specification says will be published weekly. The legacy US Privacy String is decoded character by character.

1. IAB Tech Lab, "Global Privacy Protocol String" (GPP Consent String Specification, version 1, final 28 September 2022, updated 3 November 2023). https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/Consent%20String%20Specification.md
2. IAB Tech Lab, GPP Section Information (repository state of 4 November 2026). https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Sections/Section%20Information.md
3. IAB Tech Lab and IAB Privacy, MSPA US National Technical Specification (version history through November 2026). https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Sections/US-National/IAB%20Privacy%E2%80%99s%20Multi-State%20Privacy%20Agreement%20%28MSPA%29%20US%20National%20Technical%20Specification.md
4. Same specification, version 2 text as of 19 June 2026 (commit 00ffaef). https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/00ffaefe91513785e886c83877e9b56a4ec8e88c/Sections/US-National/IAB%20Privacy%E2%80%99s%20Multi-State%20Privacy%20Agreement%20%28MSPA%29%20US%20National%20Technical%20Specification.md
5. IAB Tech Lab, California Privacy Technical Specification (November 2026 entry). https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Sections/US-States/CA/GPP%20Extension%3A%20California%20Privacy%20Technical%20Specification.md
6. IAB Tech Lab, GPP extension for the IAB Europe TCF (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Sections/EEA/GPPExtension%3A%20IAB%20Europe%20TCF.md
7. IAB Tech Lab, GPP extension for the IAB Canada TCF (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Sections/Canada/GPPExtension%3A%20IAB%20Canada%20TCF.md
8. IAB Tech Lab, "IAB Tech Lab Announces Privacy Standards Portfolio Updates ... for Public Comment" (11 August 2026). https://iabtechlab.com/press-releases/privacy-standards-portfolio-updates-to-strengthen-privacy-compliance/
9. IAB Tech Lab, Global Privacy Protocol page (last updated 12 August 2026). https://iabtechlab.com/gpp/
10. GitHub, InteractiveAdvertisingBureau/Global-Privacy-Platform, commit "Updates to US sections of the GPP" (4 November 2026). https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/commit/b997269909b0ec3c3096be4dbb4668864c6afed3