# Reading your consent string: how to confirm vendors honor what the banner recorded Source: https://consentvigil.com/blog/2026-10-12-reading-consent-string-vendor-compliance-check.html [Home](../index.md) / [Blog](index.md) / Reading your consent string: how to confirm vendors honor what the banner recorded Published 2026-10-12 Every time a visitor clicks through your consent banner, your consent platform writes a small encoded record of that choice: the consent string. It gets passed to ad vendors, tag managers, and analytics tools as the machine-readable version of what the person agreed to. Most teams treat it as plumbing they never inspect. That is a mistake, because the string is the only proof that your vendors heard what the banner said. ## What the consent string actually contains In the ad-tech world this is usually the IAB Transparency and Consent Framework string: a compact encoding of which purposes the visitor allowed, which vendors are permitted, and which legal basis each vendor claims. Outside advertising, consent platforms write their own equivalents into cookies or local storage, typically a version number, a timestamp, the notice shown, and a per-purpose allow or deny. Either way, the string is the contract between the banner and every downstream tool. Reading it is straightforward. Consent platforms include a decoder in their documentation, and browser dev tools show the stored value under Application or Storage. Paste the string into a decoder and you see the parsed choice: purpose 1 allowed, purposes 3 and 4 denied, vendor 12 permitted, and so on. Do this on your own site right now, after clicking reject all, and you may be surprised at what you find. ## The gap between the banner and the vendors The most common failure is simple: the banner records a rejection, the string encodes it correctly, and a vendor ignores it anyway. This happens when tags fire from a tag manager that never checks the string, when an embed loads its own scripts independently, or when a vendor reads a stale copy of the string cached from an earlier visit. The banner did its job. The signal chain broke downstream. A subtler failure is string drift. Some setups regenerate the consent string on every page view from the latest banner state, while others only write it once per session. If a visitor changes their choice mid-session, vendors holding the old string keep operating on outdated consent. The fix is a change listener that rewrites the string and re-notifies vendors whenever the choice changes, then verifies the new value actually propagated. ## A practical string audit you can run this week Start with three scenarios on a clean browser profile: accept all, reject all, and accept with only strictly necessary purposes. After each choice, decode the stored string and confirm it matches what you clicked. Then check what your vendors received: use the network tab to inspect the consent parameters on outgoing requests to ad and analytics endpoints, and confirm denied purposes are not being transmitted as allowed. Next, check the edge cases. Change your choice mid-session and re-decode. Load a page that includes your heaviest third-party embeds and confirm the string reaches them before their scripts execute. Clear storage, return as a repeat visitor, and confirm the string is restored rather than reset to a default. Each of these catches a real class of failure that a banner-only test misses. ## Turning the check into evidence An audit you cannot show an auditor is a hobby. Record the scenario, the decoded string, the vendor requests observed, and the timestamp, and store it alongside your other consent evidence. When a regulator asks how you know vendors honor choices, a dated log of string decodes with matching network observations is a concrete answer. It also gives your developers a regression test: run the same decode after every deploy that touches the banner, the tag manager, or vendor configuration, and the string stops drifting silently. ## Frequently asked questions ### What is a consent string, in plain terms? It is a compact, machine-readable record of what a visitor chose in your consent banner: which purposes were allowed or denied, which vendors are permitted, and when the choice was made. It is stored in a cookie or local storage and passed to vendors so their tools can respect the choice. ### How do I decode the consent string on my own site? Open your browser's developer tools, find the consent cookie or local storage entry, and paste its value into your consent platform's decoder tool. Most major platforms document their string format and provide a decoder or a test page for exactly this purpose. ### What should I do if a vendor ignores the consent string? First confirm the string itself is correct, so you know the problem is downstream. Then check whether the vendor's tag reads the string before firing, whether it caches an old copy, and whether your tag manager passes the current value. If the vendor's own script ignores a valid signal, document it and escalate through the vendor's support and your contract terms. ### How often should we check that consent strings match reality? At minimum, after every change to the banner, the tag manager, or your vendor list, plus a scheduled check each quarter. String drift usually appears right after a deploy, so wiring the decode check into your release process catches most problems before they become audit findings. ## Get a free consent audit of your website [Free consent audit](mailto:hello@consentvigil.com?subject=Free%20consent%20audit%20-%20consentvigil.com)