How to check if cookies fire before consent

Checking whether cookies fire before consent — on your own site, a client's, or a competitor's — doesn't require any special tooling. Your browser already has everything needed. Here's the exact process, step by step.

1. Start from a genuinely first-time visit

This is the step people skip, and it's the one that invalidates the whole check if you skip it. If you've visited the site before and already clicked "Accept" (or even "Reject") on its cookie banner, your browser has that choice cached — the site will correctly not re-ask you, and everything will look fine even if it isn't.

Open a fresh incognito or private window before doing anything else. That guarantees a clean slate: no cached consent, no existing cookies from that domain.

2. Open DevTools and watch the Network tab before clicking anything

In your incognito window, open DevTools (F12, or right-click → Inspect) and switch to the Network tab. Load the site — but don't click Accept, Reject, or anything else on the cookie banner yet.

Watch what loads. You're looking for requests to known tracker domains firing before you've made any choice:

• google-analytics.com or analytics.google.com — Google Analytics / GA4
• googletagmanager.com — Google Tag Manager (loads other tags, doesn't track directly itself, but its presence often means more is coming)
• googleads.g.doubleclick.net — Google Ads
• facebook.com/tr — Meta Pixel
• analytics.tiktok.com — TikTok Pixel
• px.ads.linkedin.com — LinkedIn Insight Tag
• clarity.ms — Microsoft Clarity (session replay)

If you see requests to any of these before clicking anything on the banner, that tracker is firing pre-consent — the fix, in every case, is making sure the tag is gated behind the consent choice at the tag-manager level, not just hidden from the page visually.

3. Check whether cookies fire before consent, not just after

Some tracking sets cookies without an obvious network request you'd notice at a glance. In DevTools, go to Application → Storage → Cookies and pick the site's domain. Before clicking the banner, note what's already there. A handful of first-party session cookies is normal and usually necessary for the site to function — what you're checking for is third-party tracking cookies (anything tied to an ad network or analytics vendor) showing up before you've made a choice.

4. Click Reject, then check again

This is the step most people never think to do, and it's often where the real problem shows up. Reload in the same incognito window, click Reject (or the equivalent "decline all" option) this time, then repeat steps 2 and 3.

A genuinely compliant site should show no new tracker requests or third-party cookies after clicking Reject. If the same requests fire whether you Accept or Reject, the banner is cosmetic — it's not actually gating anything, it just looks like it is.

A few things that can throw off the check

• Geo-targeted banners: some sites only show the full consent-gating banner to EU-region visitors and skip it (or use a lighter version) for everyone else, based on IP geolocation. If you're testing from outside the EU, you may see different — often worse — behavior than an EU visitor would.
• Server-side tagging: if a site has moved its Google Tag Manager to a server-side container, some tracking calls happen server-to-server and never show up in your browser's Network tab at all. A browser-only check can't catch this — it's a real, known limitation worth knowing about, not something any browser-based method solves.
• A misconfigured Consent Mode setup: some sites run Google's Consent Mode v2 but have it wired up wrong, so tags still fire (in a degraded or "pinged" form) before a choice is made. If that's what you're seeing, see why Google Consent Mode v2 isn't working for the specific things to check. If you're running this check because your ad platform's remarketing numbers look off, see is consent gating shrinking your remarketing audience for that specific angle.
• A/B tests and feature flags: occasionally a site runs a different consent configuration for a percentage of visitors. One clean check isn't a guarantee the behavior is consistent for everyone — testing more than once, or from more than one session, catches this.

For more on the underlying legal framework this is checking against, see the GDPR's own text on consent requirements — most of what a pre-consent tracker check is looking for maps directly to that article.

If you'd rather not do this by hand every time

This entire process — the incognito load, the Network tab check, the cookie inventory, the Reject-and-recheck step — is exactly what an automated scan does in about 30 seconds, and it repeats the check automatically on a schedule so a routine deploy that breaks consent gating doesn't sit unnoticed for weeks.

— Petrus, ConsentCheck founder. I ran this exact check by hand on client sites for years before building a scanner to do it automatically.