How to Verify That Cookies Are Blocked

Overview

After setting up Termly's consent banner and Auto Blocker, you may want to confirm that non-essential cookies and scripts are actually being blocked before visitors give their consent. This article walks you through how to verify blocking is working correctly using your browser's developer tools and the Termly dashboard.

Important: Seeing cookies in your browser after declining consent does not mean blocking is broken. Termly blocks scripts from running, it cannot delete cookies that were already stored in a previous session. Those cookies become inert (the scripts that would read or use them are blocked). This is standard behavior for all Consent Management Platforms (CMPs) and is fully compliant under GDPR.

Before You Start

To get an accurate test, always start from a clean state:

1. Open your website in an Incognito / Private window this clears any previously stored consent.
2. Do not click Accept or Decline on the banner yet. You want to observe the page before any consent is given.
3. Open browser DevTools:
   • Windows / Linux: F12 or Ctrl + Shift + I
   • Mac: Cmd + Option + I
4. Reload the page with DevTools open so the Network tab captures all requests from the start.

Method 1: Check the Application Tab (Cookies)

This is the quickest way to see which cookies are being set on your site.

1. In DevTools, click the Application tab (Chrome/Edge) or Storage tab (Firefox).
2. In the left sidebar, expand Cookies and click your site's domain.
3. Before giving consent, you should only see:
   • Termly's own consent cookie (e.g., termly-api-cache)
   • Cookies you have classified as Essential in your Termly dashboard
4. Click Accept All on the banner, then reload the page.
5. Return to the Application tab. You should now see additional cookies from analytics, advertising, and other third-party services.

What this confirms: Non-essential cookies were blocked before consent and only set after consent was given.

What to look for if blocking is not working:

• Non-essential cookies such as _ga, _gid (Google Analytics), _fbp (Facebook Pixel), _pin_unauth (Pinterest), or NID (Google) appearing before any consent decision was made.

Method 2: Check the Network Tab (Script Requests)

The Network tab shows whether third-party scripts are actually loading before consent this is the most reliable verification method.

1. In DevTools, click the Network tab.
2. Click the JS filter to show only JavaScript requests.
3. Reload the page (without giving consent).
4. Look at the list of scripts loading. Before consent, third-party tracking scripts (e.g., from googletagmanager.com, connect.facebook.net, analytics.google.com) should either:
   • Not appear at all, or
   • Appear as cancelled or blocked (shown in red or with a strikethrough)

Verify via Page Source

Right-click anywhere on the page and select View Page Source. Find your third-party script tags. If Auto Blocker is working correctly, you will see them modified like this:

<!-- Before consent — script is disabled -->
<script type="text/plain" data-categories="analytics" src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>

The type="text/plain" attribute prevents the browser from executing the script. Termly swaps this to type="text/javascript" only after the visitor consents to the relevant category.

What this confirms: Termly has intercepted and disabled the script tag.

Method 3: Check the Console for Termly Messages

Termly logs messages to the browser Console when Auto Blocker is active.

1. In DevTools, click the Console tab.
2. Reload the page and look for messages that begin with [Termly].

Common messages and what they mean:

Note: An empty string '' as the script source is expected for dynamically injected scripts (e.g., scripts added by tag managers or other scripts at runtime). This is not an error; these scripts are still blocked under the Unclassified category.

Method 4: Check the Consent State via the Console

Termly exposes a built-in JavaScript function you can call directly from the browser Console to see exactly which categories have been consented to.

1. Go to the Console tab in DevTools.
2. Type the following and press Enter:

Termly.getConsentState()

The output will show consent values for each category:

{
  "advertising": false,
  "analytics": false,
  "essential": true,
  "performance": false,
  "social_networking": false,
  "unclassified": false
}

• false = not consented → scripts in this category are blocked
• true = consented → scripts in this category are allowed
• essential is always true

After clicking Accept All on the banner, run the command again all categories should switch to true, confirming that Termly is correctly tracking and applying consent changes.

Note: Termly.getConsentState() is only available after the Termly embed script has fully loaded on the page. If you run it too early and get undefined, wait for the page and banner to fully load, then try again.

Method 5: Search for Blocked Scripts in the Elements Tab

You can use the browser's Elements tab to find every script that Auto Blocker has intercepted on the page. Termly marks all blocked scripts with an auto-blocked attribute directly in the HTML.

1. In DevTools, go to the Elements tab.
2. Press Ctrl + F (Windows/Linux) or Cmd + F (Mac) to open the search bar within Elements.
3. Type auto-blocked and press Enter.
4. Every script that Auto Blocker has blocked will be highlighted. They will look like this:

<script type="text/plain" auto-blocked data-categories="analytics" src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>

The data-categories attribute tells you which consent category that script belongs to. Scripts with type="text/plain" and the auto-blocked attribute are confirmed as blocked.

If you want to see or adjust how individual scripts are categorized, you can do so from the Termly dashboard using Cookies or Domain Rules (under Consent Management).

Quick Reference: Is Blocking Working?

Troubleshooting: Blocking Not Working

Scripts are loading before consent

• Confirm the Termly embed script is the first script in <head>. Any third-party script that loads before Termly will bypass Auto Blocker entirely.
• If scripts are delivered through Google Tag Manager (GTM), GTM must use consent initialization triggers. Auto Blocker cannot intercept scripts that GTM injects without this setup.
• If scripts are dynamically injected at runtime, Auto Blocker may not catch them. Use Domain Rules or a Custom Blocking Map to assign them a category.

A specific script is not being blocked

• In DevTools, go to the Elements tab and search for auto-blocked to see which scripts Termly has intercepted. Check the data-categories attribute to confirm which category each script is assigned to.
• Check whether a Domain Rule is set to "Always Allow" for that domain this overrides blocking.
• Recategorizing cookies in the Cookie Report does not affect Auto Blocker behavior. Script blocking is controlled only through Manual Blocking, Domain Rules, and the Custom Blocking Map.
• After any dashboard change, republish the banner changes do not take effect until published.

Domain Rules are not applying

• Domain Rules can take 5–10 minutes to take effect after publishing.
• If a script is still loading after adding a Domain Rule, check the Elements tab and search for auto-blocked to confirm the script's assigned category. If it was manually categorized via Manual Blocking, that takes precedence over Domain Rules update it there instead.
• A Custom Blocking Map hardcoded on the page takes precedence over Domain Rules check whether one exists on the page before the Termly embed script.
• Make sure the domain is entered with the correct subdomain. cdn.example.com and example.com are treated separately; more specific entries take precedence.