The principle
A script tag in the document has already been fetched and, in most cases, already executed. Everything done to it after that point is cleanup, and cleanup is not consent. The only durable approach is that the element is never created until the category is granted.
- Register the script with the browser API and let the runtime create it on grant
- Declare custom scripts as a named HTTPS URL and a purpose, never as inline markup that has already run
- Where a vendor supports a consent signal, establish denied defaults before its container loads
- On withdrawal, stop future loading and use the vendor’s revoke or teardown API where available; also clear applicable cookies and browser storage and address any server-side profile or suppression state
Gating your own code
For anything your own application loads, register it rather than conditionally rendering it. Registration hands the decision to the runtime, which means it is enforced consistently and it changes when the visitor changes their mind.
Register a gated script
window.StrongPrivacy.registerScript({
id: 'support-widget',
category: 'functional',
src: 'https://widget.example.com/widget.js',
async: true,
attributes: {
'data-region': 'global'
}
});Listen for `strongprivacy:change` to react to a mid-session change: tearing down a map, stopping a poller, swapping an embed back to a placeholder.
Embeds want a placeholder, not a block
A blocked video is a broken page as far as a visitor is concerned. The better pattern is click-to-load: a placeholder explaining that the content is blocked by their privacy choices, with an action to allow and view it. The runtime ships copy for exactly this.
Host the placeholder image yourself
A thumbnail pulled from the video provider’s CDN is itself a request to that provider, carrying the visitor’s IP address. If the goal is a clean pre-consent state, the placeholder cannot come from them.
What this script loader does not control automatically
- Server-side integrations, including conversions APIs: they never touch the browser
- Stylesheet and font links already present in markup; omit them, self-host them, or insert them only after the relevant condition if they must be gated
- Scripts injected by a platform surface you do not control, such as a hosted checkout
- Anything inside a mobile app shell rather than the web page
Each of those needs a different fix: a server-side consent check, self-hosting, a platform setting, or an app change. Knowing which category a problem is in saves a great deal of time.
Common questions
Is type="text/plain" rewriting good enough?
It works only where the rewrite happens before the parser reaches the tag, and it does nothing about scripts injected later by other scripts. It is a retrofit technique, not a design.
How do I prove blocking works?
Scan in each consent state in a real browser and compare what loaded. Source inspection cannot tell you what executed.
Sources and verification
Verified on . Product-behaviour statements were checked against the current implementation and tests. The links below are the verification basis recorded for this article. They support the stated facts, not a legal conclusion for every site or configuration; recheck changing vendor behaviour before relying on it in production.
- ICO: guidance on storage and access technologies
Regulator guidance
Checked
- StrongPrivacy custom-site installation guide
Product documentation
Checked
See what your own site is loading
A browser scan reports the requests and storage it observed during the sampled journey. Use configured workspace scans to compare the states and pages that matter to your implementation.