Beyond Cookie Checkers: Why SafeLaunch's Real-Browser Test Shows What Regulators Actually See

02

Why do static cookie checkers miss real violations?

A static checker downloads your HTML and searches it for known script URLs. That made sense when every tracker was a hard-coded <script> tag. Modern sites don't work that way.

• Tag managers load trackers at runtime. Google Tag Manager or Segment pulls in the Meta Pixel after the page starts. The HTML shows one container script, not the ten tags inside it.
• Single-page apps render in JavaScript. Sites built with React, Vue or most AI builders ship an almost empty HTML shell. A checker that doesn't run JavaScript sees nothing.
• Consent tools change behaviour on click. Whether Reject works depends on the consent platform's configuration, its integration with your tags, and timing. None of that is visible in source.
• Cookies are set by the browser, not the HTML. Third-party scripts write cookies on other domains. Only the browser's cookie jar shows them all.
• Self-hosted and proxied tags look first-party. Analytics served from your own domain still tracks people, and still needs consent.

03

How does SafeLaunch's real-browser cookie test work?

When SafeLaunch runs a paid audit (Launch Report or Launch Fix) on a website, it opens the page in a real browser and runs it through three separate phases. Each Reject and Accept run starts in a clean session, so one choice can't leak into the other. The free scan reads the page source and flags the trackers it can see there.

1. 01

   Before any choice

   The page loads and the browser waits. SafeLaunch records every request the page makes and every cookie set on any domain, then identifies the services behind them: analytics, advertising, session replay, chat, fonts, payments and forms. It also looks for the banner and reads its buttons.

2. 02

   After Reject

   In a fresh session, SafeLaunch clicks the Reject control and views the page again. Any non-essential tracker or tracking cookie still present is recorded as evidence that the refusal isn't being respected. If Reject is only reachable through a 'Settings' or 'Manage' layer, that is recorded too.

3. 03

   After Accept

   In another fresh session, it clicks Accept. This confirms which services your consent actually enables, the inventory your cookie notice must describe.

4. 04

   Accessibility in the same visit

   While the browser is open, the page is tested with axe-core against WCAG 2.2 AA. Missing labels, contrast failures and keyboard traps are reported alongside the consent results.

04

What does a finding from the browser test look like?

Every finding carries the evidence the browser recorded, the law it relates to in each market you selected, and the fix. A typical example:

HIGH · Advertising tracker loads before consent
Evidence: Before any choice, the browser requested connect.facebook.net
          and set the cookie _fbp (Meta Pixel). After Reject, _fbp was
          still present.
Law:      EU · ePrivacy Directive Art. 5(3); GDPR Art. 6(1)(a) & 7
          UK · PECR Reg. 6; UK GDPR Art. 7
Fix:      Load the Meta Pixel only after the visitor accepts marketing
          cookies. Remove the hard-coded tag from <head> and fire it from
          your consent tool's "marketing" category.

Launch Fix turns that into the exact code change and a prompt for your AI builder. Read how findings become copy-paste prompts.

05

Does the real-browser test matter outside Europe?

Yes, in different ways. The EU, UK and Switzerland are opt-in markets: non-essential cookies need consent first. Much of the US works on an opt-out model, but the same evidence matters. California's privacy rules give consumers the right to opt out of the sale or sharing of personal information, which includes many advertising trackers, and the California Attorney General's 2022 settlement with Sephora centred on third-party trackers sharing data after people had tried to opt out.

Brazil's LGPD, India's DPDP Act and Quebec's Law 25 also turn on whether what you say about tracking matches what happens. In every market, a list of the services your site really contacts is the foundation of an accurate privacy and cookie notice.

06

What the browser test can't see

• Pages behind a log-in. URL scans don't sign in, submit forms or make payments.
• Behaviour that depends on location, device or A/B tests outside the run.
• Server-side tracking that never reaches the browser, such as conversion APIs. SafeLaunch can find these in code when you connect a repository.
• Automated accessibility checks find many WCAG problems but can't establish full conformance. Manual keyboard and screen-reader testing is still needed.

When the browser can't open a site, SafeLaunch falls back to reading the HTML and says so in the report, rather than presenting a guess as a test result.