Checklist
TCF consent string vs runtime cookie evidence: what still fires?
A TCF consent string does not prove tags and cookies stopped. Compare it with cookies and network rows. Not a TCF implementation tutorial.
In brief
An IAB TCF consent string is a signal vendors and tags can read. A cookie audit asks whether marketing cookies, storage, and third-party requests still appeared when the string said purposes were denied or the visitor chose Reject. ConsentProbe can store that state-labeled pack. A free US-baseline scan is not an EU or California legal conclusion. This page is not a TCF implementation tutorial and not legal advice.
Not legal advice
This guide explains how to falsify, at runtime, whether tags and cookies still fire when an IAB TCF or CMP consent string, or a dashboard, says denial or limited purposes. It is not legal advice (非正式法律意见), not an IAB TCF or CMP implementation tutorial, and not a GDPR, ePrivacy, or other certificate. ConsentProbe reports are technical observations of what fired. They do not say what counsel would allow.
Last updated September 24, 2026. The CMP claims guide owns the wider claims-versus-evidence method. The Reject leftovers guide owns a Reject All failure. The evidence pack guide owns the file fields. The Consent Mode page is the sibling falsification piece for Consent Mode signals. This page stays on the TCF consent string versus cookies and network rows.
Short answer
A TCF or CMP consent string is not proof that tags and cookies stopped. The string, sometimes called a TCString, is an encoded signal the CMP exposes. Vendors and tags can read it. The audit asks a different question: did marketing cookies, storage, and third-party requests still appear when the string said purposes were denied, or when the visitor chose Reject?
Treat the TCString and the CMP UI as claims. On a clean visit, record the consent state you believe is active, capture cookies and network rows, and keep screenshots labeled by that state. If the string looks denied and Network looks like Accept, the string and the runtime disagree. The same theme sits on the Consent Mode versus runtime page. ConsentProbe can produce that state-labeled evidence pack. A free US-baseline scan is not an EU or California legal conclusion. ConsentProbe does not install a CMP and does not configure TCF. This page is not a TCF implementation tutorial and not legal advice (非正式法律意见).
String versus evidence
Three layers get mixed in CMP write-ups. Separate them before you write the finding. Stay with string and runtime disagree. Leave legal permission with counsel.
| Layer | What it is | What it does not prove alone |
|---|---|---|
| TCF or CMP consent string (TCString) | An encoded consent signal the CMP exposes | That cookies and beacons stayed off |
| CMP dashboard or UI | An operator-facing claim about purposes or vendors | That the browser network matched the dashboard |
| Runtime cookie and network evidence | What the browser actually set and requested | Legal permission, which stays with counsel |
Falsify the string on a clean visit
These steps compare a claimed state with cookies and requests. They do not decode purpose bitfields, register a vendor, or configure a CMP. You can note that a TCString or CMP API value exists. You do not need to unpack it to see whether ads cookies still appeared.
- Use a clean profile. Note the state under test: Fresh with no click, Reject All, or purposes denied if that is the claim.
- Optionally note that a TCString or CMP API value is present. Do not turn that note into a decode.
- Load the storefront once. Do not click Accept.
- Capture cookies and storage. Flag ads, analytics, and marketing IDs.
- Capture Network for known marketing hosts and tagged requests.
- Screenshot and label by state. Write one finding sentence per mismatch.
- Optional: run Accept All as a positive control so you know what on looks like.
Mismatch patterns you can observe
The rows below are observations from a labeled visit. They are not a purpose-ID table and they do not prescribe CMP vendor settings.
| Claim or assumption | What you hoped to see | Red flag |
|---|---|---|
| TCString shows denial | Ads and analytics cookies and beacons stay off on Fresh | The same fan-out as a visit that looks consented |
| Reject All with a TCF CMP | Marketing stays off after Reject and the next navigation | Reject looks like Accept |
| Dashboard shows vendors off | Storefront runtime matches the dashboard | The banner looks settled and the network is still hot |
When hand-checking TCF claims gets slow
Checking TCF claims across templates by hand is slow. ConsentProbe runs on the URL and stores state-labeled findings tied to a request, a cookie, or a screenshot.
Use the free US-baseline visit when you want the report format. Use paid EU or California scenarios when those regions are the claims. The free versus paid guide draws that line. ConsentProbe does not configure TCF or a CMP, does not install a CMP, and does not issue a certificate.
FAQ
Does a TCF consent string stop cookies by itself?
No. It is a signal. Verify cookies and network rows under the state you care about.
Is a CMP dashboard enough evidence?
No. Capture cookies, storage, and requests labeled for that state.
Where do I learn CMP claims versus evidence generally?
The CMP claims guide covers the wider method. This page stays on the TCF string versus runtime rows.
What if Reject All still tracks with TCF on?
Treat it like any Reject failure. The Reject leftovers guide is the network check. Keep an evidence pack.
How is this different from Consent Mode?
The falsify-at-runtime theme is the same. The Consent Mode page covers Consent Mode signals. This page covers the TCF consent string.
Will this page teach TCF implementation?
No. This page is a falsification check, not a TCF implementation tutorial. It is not legal advice (非正式法律意见).
Limits of this page
This page tells you how to compare a TCF or CMP consent string with cookies and network requests. It is not legal advice (非正式法律意见), not a TCF implementation tutorial, and not a certificate. ConsentProbe reports stay tied to requests, cookies, and screenshots. A free US-baseline scan is not an EU or California legal conclusion.
Related guides
Open the CMP claims guide for the wider method, the Reject leftovers guide when Reject still tracks, the evidence pack guide for the file fields, and the Consent Mode page when the stack is Consent Mode.
- CMP claims vs runtime evidence: how do you prove the banner actually works?
- Reject All Still Tracking: What to Check After You Say No
- What belongs in a cookie consent audit evidence pack?
- Consent Mode v2 vs runtime cookie evidence: what still fires?
- What does a free US-baseline cookie audit prove vs paid EU or California scans?
- How do you audit cookies across EU fresh, reject, and accept visits?
- Pre-Consent Cookie Audit: A Storefront Checklist
- Which cookie consent test should you run first?
- ConsentProbe methodology
- Pricing and listed regional products
Sources
These links cover the platform and regulatory context used in this guide. Applicability still depends on the organization and jurisdiction.
Save a US-baseline technical record
After a DIY check, run a free US-baseline audit: one browser visit outside California, with cookies, requests, and screenshots stored as evidence. That visit does not run EU reject/accept or California GPC. EU, California, and Global 2 audits can be purchased from Billing after sign-in.