Introduction
A Consent Management Platform's most critical technical job is preventing tracking scripts from firing before the user has given consent. Get this wrong and every privacy policy, cookie banner, and preference modal on your site is purely cosmetic — data still flows to third parties regardless of what the user clicked.
There are fundamentally different philosophies about how to achieve this. Some CMPs try to automatically detect and block scripts on your behalf. Others require you to manually tag each script. And a growing number rely on consent signalling protocols that tell scripts to regulate themselves. Each approach has real trade-offs in accuracy, setup effort, and risk of breaking your site.
This guide compares four widely used CMPs — Osano, Cookiebot (now part of Usercentrics), OneTrust, and CookieBeam — to help you understand which script blocking method fits your site and team.
The Two Philosophies
Every CMP uses one or both of these fundamental approaches:
1. Hard blocking — The CMP prevents scripts from executing at all until consent is granted. This can be done automatically (the CMP intercepts and holds scripts) or manually (you change your script tags so the browser ignores them until the CMP activates them). Hard blocking is the most airtight approach: no code runs, no network requests fire, no cookies are set.
2. Consent signalling — The CMP lets scripts load normally but sends machine-readable signals (such as Google Consent Mode's consent command or the IAB TCF TC String) telling each script whether it has permission to track. The script itself decides how to behave based on the signal. This is less intrusive but relies on the vendor's code actually respecting the signal.
In practice, most sites need a combination of both: consent signalling for scripts that support it (primarily the Google ecosystem), and hard blocking for everything else.
The Four CMPs Compared
The table below provides a high-level comparison of how each CMP handles script blocking, detection, and compliance. The details for each CMP follow in the sections below.
CMP Script Blocking Comparison
| Feature | Osano | Cookiebot | OneTrust | CookieBeam |
|---|---|---|---|---|
| Blocking approach | Automatic — intercepts scripts at runtime based on a curated block list | Hybrid — automatic scanner + manual data-cookieconsent tagging; auto-blocking mode also available | Manual — scripts tagged with optanon-category classes; auto-scan for discovery only | Manual — scripts tagged with type="text/plain" + data-category attributes |
| Script detection method | Records all script URLs after osano.js loads; matches against regional block list | Monthly crawler scans site and auto-categorises cookies; scripts need manual tagging for hard blocking | Auto-scan discovers cookies and scripts; manual configuration maps scripts to categories | No auto-detection — site owner explicitly tags each script with its category |
| Compliance modes | Listener (discover only), Permissive (block classified, allow unknown), Strict (block all unclassified) | Auto-blocking mode (block unrecognised scripts) or manual mode (only block tagged scripts) | Single enforcement mode — blocks scripts tagged with optanon-category; untagged scripts run freely | Single enforcement mode — only tagged scripts are managed; untagged scripts run freely |
| Dynamic script handling | Intercepts dynamically injected scripts via MutationObserver | Auto-blocking mode can catch dynamically injected scripts | Limited — primarily handles scripts present at page load | Watches for dynamically added script tags with data-category |
| Iframe blocking | Yes — separate iframe blocking feature | Yes — supports data-cookieconsent on iframes | Yes — iframes can be tagged with optanon-category | Yes — iframes can use data-category and data-src attributes |
| Cookie auto-deletion | No — blocks future execution but does not retroactively delete previously set cookies | Yes — can auto-delete cookies when consent is withdrawn | Yes — supports cookie auto-deletion on consent withdrawal | Cleanup scripts via !category prefix for manual cookie deletion on withdrawal |
| Google Consent Mode V2 | Supported | Supported — strong integration with regional defaults | Supported | Native support with configurable regional defaults |
| TCF support | Not IAB TCF certified | IAB TCF v2.2 certified CMP | IAB TCF v2.2 certified CMP | TCF v2.2 integration available |
| GTM integration | Basic integration via consent signals | Official GTM template available | Official GTM template available | GTM bridge template for Consent Mode integration |
| Over-blocking risk | High in Strict mode — known to block reCAPTCHA, payment processors, and essential services | Moderate in auto-blocking mode; low in manual mode | Low — only blocks explicitly tagged scripts | None — only blocks what you explicitly tag |
| Setup effort | Low initial setup; ongoing effort to fix over-blocking and reclassify scripts | Medium — scanner helps discovery but scripts still need tagging | High — enterprise-grade configuration with complex admin UI | Medium — requires manually tagging each script, but straightforward HTML attributes |
Osano: Automatic Discovery and Blocking
Osano takes the most aggressive approach to script blocking. Once osano.js loads as the first script in your <head>, it records all subsequent script URLs and matches them against a curated regional block list. Scripts that match known tracker patterns are intercepted before they can execute.
Osano offers three compliance modes:
- Listener mode — Discovery only. Osano observes which scripts load and categorises them, but does not block anything. Use this during initial setup to understand what your site loads.
- Permissive mode — Enforces blocking for scripts that Osano has classified as non-essential, but allows any unrecognised script to run. This is a safe middle ground during rollout.
- Strict mode — Blocks all scripts that have not been explicitly classified as essential. Any script Osano does not recognise is blocked by default until you manually approve it.
Osano also provides separate features for iframe blocking and localStorage blocking, giving broad coverage over different tracking mechanisms.
The main advantage of Osano's approach is zero-config for site owners — you add one script tag and the CMP handles the rest. However, this comes with a well-documented downside: over-blocking. Osano's Strict mode is known to block essential services like Google reCAPTCHA, payment processors (e.g. Stripe checkout), and authentication services because their URL patterns match entries in the tracker database.
Osano's own documentation explicitly acknowledges that reCAPTCHA blocking is caused by misclassifying required Google URLs as non-essential. The fix requires site owners to manually reclassify these URLs in the Osano dashboard — ironically adding the same manual work that automatic blocking was supposed to eliminate.
It is also important to note that Osano does not retroactively delete previously set cookies after a user revokes consent. Instead, it blocks future script execution, which means cookies set before revocation remain in the browser until they expire naturally or are cleared by the user.
Cookiebot (Usercentrics)
Cookiebot, now part of the Usercentrics group, takes a hybrid approach that combines automatic scanning with manual script tagging.
The core of Cookiebot's system is its monthly cookie scanner. A crawler visits your site, identifies cookies and tracking technologies, and automatically categorises them. This gives site owners a comprehensive inventory without manual auditing.
However, for hard blocking to work, scripts in your HTML still need the data-cookieconsent attribute. The scanner discovers what is on your site; the attributes tell Cookiebot which scripts to block. This means there is still a manual step for each script tag you want to manage.
Cookiebot also offers an auto-blocking mode that works similarly to Osano — it attempts to block scripts without requiring manual tagging. This mode is useful for sites that cannot easily modify their HTML, but it carries the same over-blocking risks as any automatic approach.
On the compliance side, Cookiebot has strong Google Consent Mode V2 integration with support for regional consent defaults. It is also an IAB TCF v2.2 certified CMP, making it suitable for sites that run programmatic advertising and need TCF compliance.
OneTrust
OneTrust is an enterprise-grade platform that takes a tag-level blocking approach. Scripts are managed by adding optanon-category-* CSS classes to script tags (e.g. class="optanon-category-C0002" for performance cookies). When OneTrust initialises, it scans for these classes and activates or blocks scripts based on the user's consent choices.
Like Cookiebot, OneTrust provides an auto-scan feature that crawls your site and discovers cookies and scripts. However, this scan is primarily for inventory and categorisation — you still need to manually configure which category each script belongs to in the OneTrust admin dashboard.
OneTrust's strength is its granular control. The admin interface allows highly specific rules for different regions, cookie lifetimes, consent models (opt-in vs opt-out), and more. For large enterprises managing dozens of domains across multiple jurisdictions, this level of control is valuable.
The trade-off is complexity. OneTrust's setup and configuration require significant effort, and the admin UI has a steep learning curve. It is also among the most expensive CMPs on the market, with enterprise pricing that can be prohibitive for small and mid-sized sites.
On the compliance side, OneTrust is an IAB TCF v2.2 certified CMP with strong support for Google Consent Mode and an official GTM template.
CookieBeam
CookieBeam uses a tag-based approach where you explicitly mark each script that needs consent management. There is no automatic detection or block list — you control exactly which scripts are blocked and which categories they belong to.
The mechanism is straightforward: change a script's type attribute to text/plain (so the browser ignores it) and add a data-category attribute (so CookieBeam knows when to activate it). For external scripts, replace src with data-src to prevent the browser from even downloading the file before consent.
CookieBeam also supports per-service toggles via the data-service attribute. This lets users control individual services (e.g. disable Hotjar while keeping Google Analytics) within the same cookie category.
For the Google ecosystem, CookieBeam provides native Google Consent Mode V2 support with configurable regional defaults. When your Google tags are loaded through GTM, Consent Mode signals handle the gating automatically — no manual script tagging needed for those tags. CookieBeam also includes a GTM bridge template for seamless integration.
A distinctive feature is cleanup scripts on consent withdrawal. By prefixing a category with ! (e.g. data-category="!analytics"), you can run cleanup logic when a user revokes consent — such as disabling a Google Analytics property or deleting specific cookies.
Because CookieBeam only blocks what you explicitly tag, there is no risk of over-blocking. Essential services like reCAPTCHA, payment processors, and authentication flows are never affected unless you intentionally tag them. The trade-off is that you are responsible for identifying and tagging every script that needs consent — nothing is blocked by default.
CookieBeam's philosophy is to use Consent Mode signalling for the Google ecosystem and hard blocking for non-Google scripts, giving you the best of both approaches.
1 <!-- CookieBeam: Tag-based script blocking --> 2 3 <!-- External script: replace src with data-src --> 4 <script type="text/plain" data-category="analytics" 5 data-service="Google Analytics" 6 data-src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"> 7 </script> 8 9 <!-- Inline script: add type and data-category --> 10 <script type="text/plain" data-category="analytics" 11 data-service="Google Analytics"> 12 window.dataLayer = window.dataLayer || []; 13 function gtag(){dataLayer.push(arguments);} 14 gtag('js', new Date()); 15 gtag('config', 'G-XXXXXXX'); 16 </script> 17 18 <!-- Marketing script with per-service toggle --> 19 <script type="text/plain" data-category="marketing" 20 data-service="Facebook Pixel"> 21 fbq('init', 'YOUR_PIXEL_ID'); 22 fbq('track', 'PageView'); 23 </script> 24 25 <!-- Cleanup script: runs when user REVOKES analytics consent --> 26 <script type="text/plain" data-category="!analytics"> 27 window['ga-disable-G-XXXXXXX'] = true; 28 </script>
The reCAPTCHA Problem
Aggressive auto-blocking CMPs — especially Osano in Strict mode — are known to block essential services like Google reCAPTCHA, payment processors (Stripe, PayPal), and authentication services because their URL patterns match entries in tracker databases.
For example, reCAPTCHA loads scripts from google.com and gstatic.com domains that are also used by Google Analytics and Google Ads. An auto-blocking CMP that blocks all Google tracking URLs will inadvertently block reCAPTCHA, breaking form submissions, login flows, and bot protection across the entire site.
The fix in every case is manual: you must log into the CMP dashboard and reclassify the blocked URLs as "necessary" or add them to an allow list. This effectively negates the main selling point of automatic blocking — you end up doing manual configuration anyway, but only after something breaks in production.
Manual tag-based CMPs avoid this problem entirely because essential scripts are never tagged for blocking in the first place. You only block what you explicitly choose to block.
Which Approach Should You Choose?
The right approach depends on your site's architecture, your team's technical capabilities, and which third-party scripts you use. Most sites benefit from a combination of methods.
Choosing Your Script Blocking Strategy
Use manual tag-based blocking if:
You have direct control over your HTML, you want precision over which scripts are blocked, and you want to avoid false positives that break essential site functionality like payments or CAPTCHA.
Use automatic blocking if:
You have many third-party scripts that you did not add yourself, your team is non-technical and cannot modify HTML, or you want a zero-configuration starting point and are willing to fix over-blocking issues as they arise.
Use Consent Mode signalling if:
Your tracking scripts are primarily from the Google ecosystem (GA4, Google Ads, Floodlight), they are loaded through Google Tag Manager, and you want to benefit from cookieless conversion modeling for users who decline consent.
Use a combination if:
You have Google tags that should use Consent Mode (loaded via GTM) plus non-Google scripts hardcoded in your HTML that need manual blocking (Facebook Pixel, Hotjar, TikTok, etc.). This is the most common real-world scenario.
The Industry Direction
The consent management industry is steadily moving toward Consent Mode signalling — letting scripts self-regulate based on consent state — rather than hard-blocking scripts from loading entirely.
Several forces are driving this shift:
- Google officially recommends Consent Mode V2 for all sites using Google tags, and has made it a requirement for personalised advertising in the EEA.
- Hard blocking breaks things. Automatic blocking CMPs routinely cause support tickets when essential services are inadvertently blocked. Consent Mode avoids this because scripts still load — they just operate in a restricted mode.
- Cookieless conversion modeling. With Consent Mode, Google tags can send cookieless pings (containing no personally identifiable information) even before consent. Google uses these pings for statistical conversion modeling, helping advertisers recover data that would be completely lost with hard blocking.
However, hard blocking remains essential for non-Google vendors that do not support Consent Mode or any equivalent signalling protocol. Facebook Pixel, TikTok Pixel, Hotjar, and dozens of other tools have no self-regulation mechanism — if the script loads, it tracks. For these scripts, the only GDPR-compliant option is to prevent them from executing entirely until consent is given.
Best Practice: Belt and Braces
Use Google Consent Mode V2 for your Google tags (loaded through GTM) so they can self-regulate and provide cookieless conversion modeling. Then use manual script blocking (with data-category attributes) for all non-Google scripts hardcoded in your HTML — Facebook Pixel, Hotjar, TikTok, LinkedIn Insight, and any other vendor that does not support consent signalling. This two-layer approach gives you the best of both worlds: maximum data recovery from Google tags and airtight blocking for everything else.