Script Blocking
ConsentStack automatically detects and blocks third-party scripts until your visitors give consent.
ConsentStack finds the third-party scripts running on your site and blocks them until your visitors consent to the relevant category. No manual tagging required for known scripts. It just works.
How scripts are detected and categorized
When a visitor loads your page, ConsentStack scans for third-party scripts and checks each one against a built-in database of 900+ known tracker patterns from 900+ vendors. If a script belongs to a recognized vendor (Google Analytics, Meta Pixel, HubSpot, and hundreds more) it is automatically assigned to the right consent category.
Scripts from domains that are not in the database are flagged as unassigned in your dashboard so you can review and categorize them yourself.
Two ways to categorize scripts
| Method | How it works | When to use it |
|---|---|---|
| Automatic | ConsentStack recognizes the script's domain and assigns a category based on its known vendor database. | Works out of the box for the vast majority of third-party scripts. No action needed. |
| Manual rules | You create a custom rule in the dashboard for a specific domain, assigning it to any category you choose. | For proprietary or niche scripts that the vendor database does not cover. |
Manual rules always take priority. If you create a custom rule for a domain that is already auto-categorized, your rule wins.
What blocking looks like in practice
Scripts are stopped before they execute, not cleaned up after the fact. This is an important distinction: no tracking code runs until your visitor has actively given consent for that category.
When a visitor gives consent:
- Blocked scripts activate immediately. There is no page reload required. Scripts in the consented category start running right away, in their original page order. If a tracker has multiple scripts (for example, a config script and a pageview script), they execute in the correct sequence: the config script loads and finishes before the pageview script starts.
When a visitor revokes consent:
- Already-executed scripts cannot be un-run. A script that has already loaded and sent data cannot be retroactively stopped. ConsentStack shows the visitor a gentle reminder to refresh the page, which clears the scripts from memory and re-applies blocking.
The key trust signal: scripts are blocked before execution, not cleaned up afterward. Your visitors' data is never sent to a third party without their consent.
For developers
If you need more control, you can manually tag any script with a data-cs-category attribute to assign it to a specific consent category. This is useful for inline scripts or cases where you want to override automatic detection.
For implementation details, see SDK installation.
Framework caveat: SSR-emitted preloads
ConsentStack intercepts third-party scripts at the moment their src is set in JavaScript. This catches every standard tracker bootstrap pattern (Google Tag Manager, HubSpot, Microsoft Clarity, Meta Pixel, and so on). It does not catch a <link rel="preload" as="script"> tag that the browser receives in the initial HTML, because the browser's preload scanner runs before any JavaScript and dispatches the fetch directly.
This matters when a framework auto-emits preload links. Next.js's <Script> component and @next/third-parties (<GoogleTagManager>, <GoogleAnalytics>) both render <link rel="preload" as="script"> into the SSR'd HTML. If you put one of these in your root layout for a tracker, the preload fetches the tracker URL before ConsentStack can intercept, and the third party may set cookies on its own domain.
Two ways to avoid this in Next.js:
- Inline the bootstrap snippet with
dangerouslySetInnerHTML. The inline<script>has nosrc, so no preload is emitted, and the runtime injection it performs is intercepted normally. This is the simplest pattern for layout-level trackers. See Framework Guides for the full pattern. - Gate
<Script>on a consent hook. Wrap it in a client component that returnsnulluntiluseConsentValuereports the relevant category as granted. The SSR pass rendersnull, so no preload appears in the initial HTML.
This caveat does not apply to plain HTML, Vue, Nuxt, Astro, SvelteKit, or vanilla JS sites that load trackers via the standard inline bootstrap snippet. It is specific to frameworks that emit SSR resource hints for declarative <Script>-style components.
What's next
- Learn about consent models and how ConsentStack decides what your visitors see
- See how to review and manage detected scripts in the dashboard