Cookies set before consent: how to find and block them

Cookies set before consent are cookies written or read before a visitor makes a choice, when that activity requires permission. A banner can still appear while hardcoded scripts, pixels and embeds send requests early, so checking the banner alone misses the problem.

What counts as a cookie set before consent?

A cookie set before consent is a cookie stored before a visitor has agreed to storage that requires consent. Reading an existing cookie without the required permission raises the same issue.

For sites subject to EU and EEA ePrivacy rules, Article 5(3) covers storing information on a visitor's device and accessing information already there. The EDPB's technical guidelines explain that the rule concerns "information", regardless of whether it is personal data. The guidelines also cover tracking pixels and links. Distributing those trackers can involve storage through caching, even without permanent cookies, and collecting identifiers can involve access.

The Planet49 decision confirms that consent for cookie storage must be active. A pre-ticked checkbox does not provide valid consent. This applies even when the stored information is not personal data.

Article 5(3) itself contains an exemption for storage strictly necessary to provide an information society service explicitly requested by the visitor. The EDPB's Cookie Banner Taskforce report warns about wrongly classifying cookies as essential. It also states that a controller's legitimate interests cannot justify placing or reading cookies under Article 5(3).

These rules concern sites subject to the relevant EU and EEA requirements. Other jurisdictions have their own rules. Seek legal advice if you need to determine which rules apply to your site or whether the exemption covers a given cookie.

Why do hardcoded tags escape banners?

Hardcoded tags can escape a banner because the browser starts requesting resources from the page's HTML before the consent script can control them. The browser does not wait for a visitor to choose before processing ordinary markup.

For example, a page may contain an advertising <script src="..."> or video <iframe src="...">. When the browser discovers that address, it can request the resource immediately. The browser preload scanner explained by web.dev can find resources in raw HTML before the main parser reaches them.

An inline tracking script above the banner loader can execute first, too. Even if the banner appears almost immediately, a request already sent cannot be taken back. Removing a script element afterward cannot undo the network activity.

Every client-side consent tool shares this limit. A tool can delay scripts it controls, but it cannot reliably prevent an earlier fetch from markup already handed to the browser. Placing a banner script near the top of the page helps with ordering, but hardcoded tracker URLs still need to be moved under consent control.

How do you find them?

Find early tracking by inspecting a fresh page load before touching the consent banner. Check both stored data and outgoing requests, since a tracker can send information without leaving a visible cookie.

1. Start with a fresh private window. Open Chrome or Edge in Incognito or InPrivate mode. Open a blank tab and press F12 or Ctrl+Shift+I to open Developer Tools before entering your site's address. On a Mac, use Cmd+Option+I. A fresh session reduces interference from earlier consent choices.

2. Capture the initial load. Select the Network tab, make sure recording is enabled and turn on Preserve log. Enter the page address and let it load. Leave the banner untouched. Keep the Network list for comparison with what happens after consent.

3. Inspect cookies and storage. Open Application > Storage > Cookies and inspect the entries for your site and any listed third-party domains. Check Application > Local Storage as well. Expected before a decision: no storage that requires prior consent. Other storage may appear, so investigate its purpose before treating it as a violation.

4. Inspect requests. Return to Network and filter by the hostnames used by your analytics, advertising and video services. Open suspicious entries to inspect their timing, initiator, request details and any Cookie request headers or Set-Cookie response headers. Expected before consent: controlled trackers are held back. A network request alone does not prove a cookie was written, while an empty Cookies panel does not prove tracking never occurred.

5. Find hardcoded markup. Right-click the page and choose View page source, or use Ctrl+U. Search for <script, <iframe, src= and your tracker hostnames. A direct tracker URL in src deserves inspection. Also check inline script blocks. Page source shows delivered HTML, so scripts inserted later by JavaScript need separate inspection in DevTools.

6. Run an independent page check. Use CookieConsentHQ's free tool to check your site for cookies set before consent. It flags early cookies, hardcoded tracker tags and Google Consent Mode v2 defaults and signals. The checker examines one page from one location. Run it on each key template, including the home page, a blog post and checkout. Different regional banners may produce different results elsewhere.

After the untouched-load check, try accepting the relevant consent category and watch the Network list again. Expected after acceptance: the permitted trackers can start loading. Repeat the before-consent test in another fresh private session after making any fix.

How does automatic prior blocking work?

Automatic prior blocking holds known tracker scripts until the visitor allows the matching consent category. After acceptance, the consent tool releases those scripts so the browser can load them.

The essential distinction is who controls the first load. A script kept behind a consent decision has not yet been given to the browser as an immediately fetchable tracker. A hardcoded <script src> in the initial HTML may already be on its way by the time a banner script runs.

Move any hardcoded tag that requires prior consent under consent control. For example, remove the direct tracking tag and load it through a tag manager trigger that waits for the matching consent choice. Alternatively, let your consent tool insert or enable the script only after permission. Check that the old HTML tag is gone so the tracker is not loaded through both routes.

CookieConsentHQ provides automatic tracker blocking for known trackers. That handles the trackers it recognizes, while hardcoded tags still need to be checked for early requests. Rerun the private-window test after changes. Before consent, expect controlled tracking requests to be absent. After consent, expect allowed scripts to load. For the Google tags, check that Consent Mode v2 is working as well.

What about YouTube and map embeds?

YouTube and map embeds need the same before-consent checks as tracking scripts. An <iframe src> in the delivered HTML can start loading outside content as soon as the browser finds it.

YouTube's guide to Privacy Enhanced Mode says it prevents embedded video views from influencing the visitor's YouTube browsing experience. Ads served in that mode are non-personalized, and video views are not used to personalize ads outside the site. You enable the mode by changing the embed domain to www.youtube-nocookie.com.

The help page does not say Privacy Enhanced Mode avoids all cookies or browser storage. Test the embed rather than treating its domain name as proof that consent is unnecessary.

For a Google Maps embed, use the same fresh-window procedure. Look for requests before consent and inspect Cookies, Local Storage and relevant Network entries. Determine what needs consent based on your findings and applicable rules, without assuming a particular cookie list.

A click-to-load placeholder avoids putting the active iframe URL in the initial src. With CookieConsentHQ, an embed can use this markup:

<iframe
  title="YouTube video"
  data-cchq="marketing"
  data-cchq-src="https://www.youtube-nocookie.com/embed/VIDEO_ID">
</iframe>

CookieConsentHQ displays a placeholder with a one-click allow button for that embed. The data-cchq-src attribute keeps the URL out of the iframe's ordinary src until it is enabled. Apply the same idea to map frames that require consent.

Test the updated page in a fresh private window. Expected before a choice: the gated iframe has not fetched its outside content. Expected after the visitor permits it: the iframe can load. Inspect both states, including storage and requests, before considering the fix complete.