Home / Consent Mode checker

The Consent Mode checker that reads the hits

A banner that looks right and gates nothing is the most common consent bug there is. The only place it is visible is in the requests the page sends while the answer is still no.

Consent Mode is not a switch, and that is why it is hard to check. It is a sequence: a set of defaults that must be in place before any Google tag loads, then an update carrying what the visitor actually chose. Get the order wrong and every screen you can look at still shows four green boxes.

Tag Master reads the sequence rather than the state, and reads the consent signal riding on each individual request — gcs and gcd, decoded, next to the hit that carried them.

What a CMP's own preview cannot tell you

• Whether the defaults arrived first. A default set after the tags have already loaded is not a default. The CMP reports that it pushed one; it cannot report what had already gone out.
• What each hit actually carried. Under Consent Mode a denied hit still leaves the browser — flagged, cookieless, but sent. "No hit" and "a hit that told Google not to use it" look identical from the banner's side and are entirely different in the reports.
• Anything the CMP does not control. A tag added outside the consent tool, a pixel hard-coded in the theme, a vendor loaded by another vendor — none of it appears in a consent tool's own list, because the list is its configuration, not the page's behaviour.

The part Consent Mode does not cover

Consent Mode is a Google protocol. Meta, TikTok, LinkedIn, Criteo and the rest do not read ad_storage at all — they are gated, if at all, by the consent tool refusing to load their tag. When that gating is misconfigured, the Google tags behave impeccably and a pixel keeps sending purchases to an advertising platform under a denied answer.

That is the finding worth having, and it is not visible in any Google tool because it is not a Google problem. The panel lists every vendor that kept firing while ad consent was denied, which is a different question from whether Consent Mode is configured correctly. The longer guide works through reading the signals off the hits themselves.

Testing the answer you did not give

Most consent testing checks the accept path, because that is the one that produces data to look at. Reject is where the interesting failures are, and it needs a clean profile: a stored answer from a previous visit replays before the banner ever appears, so a second run is not a test of the first load.

Reproducing a denied state without clearing everything is the other route — suppress a vendor's hits and watch what the rest of the stack does about it. Blocked hits stay in the list, so you can still read what would have been sent, which is the part a browser's own blocking never gives you.

Where the consent tool still wins

Everything about the choice itself. Whether the banner meets the design requirements of a particular regulator, whether the vendor list matches your TCF registration, whether the record of consent is being stored the way your legal team agreed — that lives in the consent platform and nowhere else. A network debugger can tell you what the page did with the answer. It cannot tell you whether the answer was collected properly, and no amount of reading requests will change that.

Questions

How do I check whether Consent Mode V2 is set up correctly?

Read the sequence, not the state. Confirm the defaults are in place before any Google tag loads, that they deny ad_storage, ad_user_data, ad_personalization and analytics_storage, and that an update follows the visitor's choice. Four green boxes after the fact prove none of that.

What are gcs and gcd?

gcs is the consent state a Google hit was sent under — G100, G111 and so on. gcd carries the fuller Consent Mode V2 picture including whether each signal was defaulted or updated. Both travel on the request and both are decoded per hit.

Does it detect tags that fire after consent is denied?

Yes, and that is the check most worth running. Non-Google platforms do not read Consent Mode signals at all, so a Meta or TikTok pixel firing under a denied answer is a gating failure the Google tools cannot see.

Do I need a clean browser profile to test?

For the first-load behaviour, yes. A stored answer from an earlier visit replays before the banner appears, so what you are testing on the second run is the replay, not the default.

Does this replace a consent management platform?

No. A CMP collects and records the choice; this checks what the page did with it. The two answer different questions and a compliant setup needs both to be right.

Guides

The longer form, on the parts that catch people out.

• Debugging Consent Mode V2: gcs, gcd and the violations nobody catches — Read consent parameters straight from the hits, tell a default apart from an update, and find the vendors that fire regardless of what the banner says.
• Testing tracking without polluting production analytics — Test purchases end up in real reports. How to stop the hits at the browser, in one tab only, and still see everything that would have been sent.
• The email that left in plain text — How to verify Google Ads Enhanced Conversions on the wire: the two shapes a hashed field takes, the four ways it goes wrong, and why the UI cannot tell you.
• Finding every tracking tag on a page — Why a tag scanner that reads the HTML misses tags loaded after the page does, and how to get the real list by reading the requests instead.
• Test Events for TikTok, Snap, UET and five more — Everyone knows about DebugView and Tag Assistant. Every other platform has the same thing, switched on by a cookie almost nobody documents — here is the full list.
• How to debug server-side GTM — Why proxied hits vanish from most debuggers, the four signals that reveal an sGTM setup, and how to connect a server preview session.

The other term pages: GTM debugger, GA4 debugger, dataLayer inspector, Meta Pixel debugger