How to Block Scripts Until Consent Is Given: Three Methods Compared

The Problem: Tags That Fire Too Early

A consent banner only works if the tags behind it respect the visitor's choice. The most common failure is simple: the banner appears, but analytics and ad scripts have already loaded and set identifiers before anyone clicked anything. Fixing that means blocking scripts until consent is given. There are three practical ways to do it.

Method 1: Rewrite the Script Type

Browsers only execute a script element when its type is a JavaScript type. If you change the type to text/plain, the browser ignores the script. You then add a data attribute that records which consent category the script belongs to:

Good for: a handful of known inline or external scripts in your templates. Watch out for: scripts injected by other scripts, which never pass through your templates and so are never rewritten.

Method 2: Gate Tags in a Tag Manager

If your tags live in Google Tag Manager or a similar tool, you can leave the container on the page and control firing with consent-aware triggers. Each tag is given a consent requirement, and the tag manager only fires it when the matching consent state is granted. The big advantage is central control: marketing can add tags without touching templates, and the rule travels with the tag.

Good for: sites with many marketing tags. Watch out for: hard-coded scripts that sit outside the container, and custom HTML tags that load further scripts of their own.

Method 3: Load Scripts Dynamically on Consent

Here you remove the script tags from the page entirely and write a function that injects them only after a consent event. This is the cleanest option for single-page applications and for developers who want full control:

  1. Listen for the consent callback from your CMP.
  2. Check which categories were granted.
  3. Create a script element, set its source, and append it to the document.
  4. Run any initialisation code in the script's load handler.

Good for: modern applications with a build step. Watch out for: forgetting to handle a returning visitor, whose stored choice must trigger loading on page load without a new click.

Handling Withdrawal

Blocking before consent is half the job. If a visitor later withdraws consent, stop calling the tools and make sure they do not keep reading or writing identifiers. Removing a script from the page does not remove code already in memory, so a reload after withdrawal is often the simplest reliable approach.

Which One Should You Choose?

How to Test It

  1. Open a private window with cache cleared.
  2. Open the browser developer tools on the Network and Application tabs before loading the page.
  3. Load the page and do not touch the banner. Confirm no analytics or advertising requests are sent and no related cookies or storage entries appear.
  4. Accept only one category and confirm that only the matching scripts load.
  5. Reject everything, reload, and repeat the first check.
  6. Withdraw consent and verify the behaviour described above.

Where FlexyConsent Fits

FlexyConsent supports IAB TCF 2.4 and Google Consent Mode v2, and is a Google-certified CMP (CMP ID 317). Whichever blocking method you choose, the banner's job is to give your code a clear signal of what the visitor chose. Your job is to make sure every script obeys it.

Key Takeaways

← Blog Read All →