How to check that no cookies are set before consent

To check that nothing is set before consent, open your site in a clean browser profile with the developer tools already open, load the page without touching the banner, then read two panels: the cookies and storage in the Application tab, and the requests to third-party hosts in the Network tab. Only strictly necessary items should appear. Then click Reject all and repeat: nothing new should appear. The whole test takes about five minutes per page, and it is the same check a regulator's investigator runs.

Why test it yourself?

Because a banner on the screen proves nothing about the scripts behind it. The CNIL's largest cookie fines, including Shein (€150 million, decision of 1 September 2025) and American Express (€1.5 million, decision of 27 November 2025), cite cookies placed before the visitor chose or after they refused. Tag managers, plugins and hard-coded snippets added by someone else are the usual cause, and they change without anyone touching the banner.

What are you looking for?

Three kinds of evidence, because article 5(3) of the ePrivacy Directive covers storing and reading information on the device, not only cookies:

• Cookies from analytics and advertising: names such as _ga, _gcl_au, _fbp, _uetsid or _uetvid, and third-party cookies on ad domains.
• Local and session storage entries written by trackers.
• Requests to tracking hosts: analytics collection endpoints, advertising pixels, session recorders. The EDPB's guidelines on the technical scope of article 5(3) treat tracking pixels and similar techniques as covered too.

What may be there before a choice: the consent cookie itself, a session cookie, a load balancer or security cookie, a shopping cart. Those are strictly necessary for a service the visitor asked for.

How do you prepare the browser?

Use a fresh browser profile, or clear the site's data first (Chrome: Application, Storage, Clear site data). A private window works for first-party cookies, but note that Chrome's incognito mode blocks third-party cookies by default, and Safari blocks them in every window, so a private window can hide the very cookies you are looking for. The Network tab still shows the requests either way, which is why it is the more reliable evidence.

Open DevTools before loading the page (F12, or Cmd+Option+I on a Mac). In the Network panel, tick Preserve log so requests survive reloads, and Disable cache to behave like a first-time visitor.

How do you run the test?

Follow the numbered steps below the article; here is what to look at in each panel.

Application, Storage, Cookies. Chrome lists cookies per origin with Name, Value, Domain, Path, Expires / Max-Age, HttpOnly, Secure and SameSite. Select your site's origin and read the names. Check every origin in the list: third-party cookies appear under the frames that set them. Then look at Local storage and Session storage in the same panel. In Firefox, the Storage tab shows the same information.

Network. Under the filter bar, open More filters and tick 3rd-party requests to show only requests to other origins. Look for analytics and advertising hosts: google-analytics.com, googletagmanager.com, doubleclick.net, facebook.com, connect.facebook.net, bat.bing.com, clarity.ms, hotjar.com, analytics.tiktok.com. Click a request and open its Cookies tab to see cookies sent or set by it.

Console. Typing document.cookie lists the cookies readable by scripts (not HttpOnly ones). If your banner marks blocked scripts with type="text/plain", document.querySelectorAll('script[type="text/plain"]') shows the tags waiting for consent.

How do you read the results?

The Consent Mode row deserves a word. In advanced mode, Google tags load with consent denied and send measurements without cookies; that is Google's design, and whether such pings are acceptable before consent is a question for your supervisory authority. If you want nothing sent to Google before a choice, use basic mode, as described in the Consent Mode guide.

What do you do when something leaks?

Find where the tag comes from: the page source (hard-coded), the tag manager (a trigger on page view), a CMS plugin, or a script that loads another. Then block it: mark the script tag so it waits for its category, move embed URLs to a placeholder attribute, or change the tag manager trigger to a consent event. Block scripts until consent covers the four methods. Retest after every fix.

How often should you repeat it?

After every change to the tag manager, every new plugin or embed, every theme update, and at least monthly on the main templates: home, an article, a product page, the checkout, a page with a form. Add the test to the cookie audit checklist. Keep a screenshot of each panel with the date; it is useful evidence if a complaint arrives.

Can a scanner do this for you?

Partly. A scanner crawls more pages than you will test by hand and names the providers it finds. Cookiequiet's free cookie scanner checks 5 pages without an account, reads scripts, iframes and Set-Cookie headers, and detects whether Consent Mode and another consent tool are present. Its limit is that it reads the HTML without running JavaScript (unless the rendered-HTML option is configured), so cookies set purely by scripts are listed from its provider database rather than observed. The DevTools test above is what confirms the behavior in a real browser. If the test shows leaks, Cookiequiet's setup is one script tag placed before your other scripts, with Reject all on by default, Consent Mode v2 switched on in the snippet the dashboard gives you, and an auto-blocker that holds about 80 known trackers until consent.