To block cookies on your website until visitors consent, stop every non-essential script and embed from running at page load, then release only the categories each visitor accepts. You can do it three ways: mark scripts by hand so the browser ignores them, gate tags in Google Tag Manager with Consent Mode, or let a consent banner's auto-blocker hold known trackers. Showing a banner is not enough on its own. Under the ePrivacy Directive and the GDPR, analytics scripts, advertising pixels and social embeds must not fire before the visitor's choice, whatever the banner says.
The French data protection authority, the CNIL, made this point expensive for Shein in September 2025. Its €150 million fine followed findings that advertising cookies were placed the moment visitors landed on the site, before any interaction with the banner, and that refusing did not stop them. The same day, Google was fined €325 million over ads shown between Gmail emails and invalid consent to advertising cookies when people created a Google account. In 2025 as a whole, the CNIL issued 83 sanctions totalling €486.8 million, and 21 organisations were sanctioned over cookies and other trackers.
Blocking cookies until consent: what the law requires
Article 5(3) of the ePrivacy Directive requires prior, informed consent before any information is stored on or read from a visitor's device, unless it is strictly necessary to provide the service the visitor asked for. The GDPR (Article 4(11)) then defines valid consent: freely given, specific, informed and unambiguous. Pre-ticked boxes do not count. Scrolling does not count.
This creates a two-step obligation: prevent non-essential cookies from being set before consent, then release them only after valid consent.
Which cookies must be blocked
Not every cookie needs prior consent, which is why cookie categories matter.
| Category | Examples | Consent required? |
|---|---|---|
| Strictly necessary | PHPSESSID, csrf_token, load balancer cookies | No |
| Functional or preference | pll_language, currency_pref | Often no, when it stores a setting the visitor chose. Yes if reused for analytics or ads |
| Analytics or statistics | _ga, _ga_<container-id>, _hjSessionUser | Yes in most EU countries, with narrow national exemptions |
| Marketing or advertising | _fbp, _gcl_au, IDE | Yes |
Strictly necessary cookies are the clearest exemption: session identifiers, security tokens and load-balancing cookies. A cookie that remembers a language the visitor chose is usually exempt too. The CNIL lists interface personalisation such as a language choice among the trackers that need no consent, as long as that personalisation is an expected part of the service. The same cookie needs consent if it is reused for analytics or advertising.
National rules differ for analytics. German authorities treat most analytics as needing consent under section 25 of the TDDDG, which has the same two exemptions as Article 5(3). The CNIL allows a narrow exemption for audience measurement under strict conditions, including a 13-month cookie lifetime. If you are unsure, block everything except strictly necessary cookies by default.
Browser blocking and website blocking are different jobs
Browser blocking protects one visitor. Website blocking is the site owner's legal duty. Visitors can block cookies themselves: Safari blocks all third-party cookies by default through Intelligent Tracking Prevention (ITP) and deletes cookies created by JavaScript after 7 days without a visit, and Firefox's Total Cookie Protection keeps each site's cookies separate. Chrome still allows third-party cookies by default. They are blocked in Incognito, and users can turn them off in Chrome's settings.
None of that satisfies the website operator's obligation. The ePrivacy Directive requires the operator to get consent before placing cookies, not to hope the browser will refuse them. A site that fires tracking scripts without consent breaks the rule even if many of its visitors use Safari.
Three technical approaches to cookie blocking
There are three main ways to stop non-essential cookies from loading before consent. They differ in effort, reliability and upkeep, and they all follow the same sequence.
What blocking until consent looks like on one page load
1. Manual script markup
This method changes each third-party script so the browser treats it as inert text. Set the type attribute to text/plain, then add an attribute that tells the consent banner which category the script belongs to. With Kukie.io, the attribute is data-cc-category:
<!-- Before -->
<script src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
<!-- After -->
<script type="text/plain" data-cc-category="analytics" src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>The browser does not run a script whose type is text/plain. When the visitor accepts the matching category, the banner re-inserts the script as JavaScript and it runs.
Embeds such as YouTube videos, social widgets and maps work the same way. Move the address out of src into a data attribute, so the iframe loads nothing until consent: with Kukie.io that is data-cc-src next to data-cc-category. When it is turned on, Kukie.io's iFrame blocking holds the common embeds automatically and shows a placeholder in their place.
Manual markup gives complete control but scales poorly. Every new script and embed must be tagged one by one, and a single missed tag sets cookies before consent.
2. Google Tag Manager with Consent Mode
If your scripts are deployed through Google Tag Manager (GTM), you can make each tag wait for consent. Set default consent states, create consent-aware triggers and configure tags to respect those states.
The critical step is setting the Google Consent Mode v2 defaults before any Google tag loads. This snippet goes first in the <head>, before the GTM container:
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('consent', 'default', {
ad_storage: 'denied',
analytics_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
wait_for_update: 500
});
</script>With every type denied by default, Google tags with built-in consent checks (GA4, Google Ads, Floodlight) adjust on their own. In basic mode the tags do not fire until consent is granted. In advanced mode they send cookieless pings, and Google models the conversions it cannot measure.
For tags without built-in consent checks (Meta Pixel, LinkedIn Insight Tag, Hotjar), create a custom event trigger that listens for a consent event, such as cookie_consent_update, and fires only when the relevant category is granted. Assign it to each non-essential tag so the tag stays dormant until the banner pushes the event to the data layer. Check your Consent Mode defaults after any change, because a default that starts as "granted" lets every Google tag set cookies on page load.
3. Automatic blocking by the consent banner
Most consent banners can block automatically. Automatic script blocking works only if the banner script loads first in the <head>, where it can intercept known third-party scripts before they run. This is the fastest route for sites with many third-party integrations.
Auto-blockers decide what to hold in two different ways. Some depend on a list the platform builds from regular cookie scans: a new marketing tag added between scans is not on the list, so it fires unblocked until the next scan. Others, including Kukie.io's, match scripts against built-in patterns for known trackers in the visitor's browser, so a newly added Meta Pixel or Hotjar tag is held without waiting for a scan. You can add your own blocking domains for services the patterns do not know.
Both kinds have limits. An auto-blocker can hold a script that should run, or miss one that should not. A plain <script src> tag written straight into your page's HTML can start loading before any blocker sees it, so tag those by hand with the manual markup above.
What "Blocked until accepted: No" means in a scan report
Some cookie scan reports list each cookie with a status such as "Blocked until accepted by user". A "No" means the scanner saw that cookie set before any choice was made: the script behind it ran on page load, and the cookie reached the visitor's device without consent.
The usual causes are a script that sits above the banner script in the <head>, a tag hard-coded into a theme template where the auto-blocker cannot catch it in time, a tag in Tag Manager without a consent trigger, or a cookie classified as necessary when it is not. To fix it, find the script that sets the cookie (the Set-Cookie header or the script's domain points to it), then tag it with the manual markup, add a consent trigger in Tag Manager or move the banner script above it. Scan again to confirm the status has changed.
Common mistakes that let cookies through
Even sites that block cookies often get the details wrong. In January 2025, the UK's Information Commissioner's Office communicated concerns to 134 of the top 200 UK websites it reviewed. In April 2025, the Dutch data protection authority warned 50 organisations about misleading cookie banners.
- The banner script loads too late. If it is not the first script in the
<head>, other scripts run before the blocker starts. Performance plugins that defer or reorder scripts are a common cause. - Consent Mode defaults to "granted". A default of "granted" before the visitor interacts lets Google tags set cookies on page load, the opposite of what the law requires.
- A banner without blocking. Showing a banner that does not stop scripts from firing changes nothing. Regulators inspect network traffic, not just the design.
- Refusing does not stop tracking. In the Shein case, cookies kept being set after visitors refused. Clicking "Reject all" must stop new cookies from loading and should remove the ones already set.
How to verify cookie blocking works
After setting up any blocking method, test in a private browsing window before you touch the banner.
In Chrome DevTools, open the Application tab and expand Cookies. Before consent, the only cookies present should be strictly necessary ones and the banner's own consent cookie. Any _ga, _fbp or similar tracking cookie at this stage means blocking has failed.
Check the Network tab too. Filter by third-party domains such as google-analytics.com and connect.facebook.net, then reload. A request to those domains before consent means a script fires too early.
Run a cookie scan after each change to your third-party integrations. Automated scans catch regressions that manual testing misses, such as a developer pasting a Meta Pixel snippet straight into a template and bypassing the tag manager.
Server-side tracking still needs consent
Server-side tracking moves data collection from the browser to a server endpoint you control, which reduces reliance on browser cookies. It can set cookies through HTTP headers with longer lifespans than Safari allows for cookies created by JavaScript. Safari caps those server-set cookies at seven days as well when the server sits behind a third-party CNAME or has a different IP address from your site.
It does not remove the consent requirement. If the server-side setup collects personal data, identifies visitors or shares data with third parties, the same GDPR and ePrivacy rules apply. Article 5(3) attaches to storing or reading information on the visitor's device, and a cookie set by your server is still stored on that device.
Server-side tracking can improve data accuracy and cut browser-side weight, but it is not a way around consent.
Questions about blocking cookies before consent
Do I need to block cookies if my website only targets US visitors?
It depends on the state. The CCPA and CPRA use an opt-out model rather than opt-in, so prior blocking is not required in California. If visitors from the EU or the UK reach your site, the prior consent rule applies to them, and geo-targeting can show each region its own consent model.
Can I use Google Analytics without blocking it first?
In most EU countries, no. German authorities treat most analytics as needing consent, and the CNIL's exemption for audience measurement applies only to tools set up to meet strict conditions. Blocking GA4 until the visitor accepts analytics cookies is the safest default.
What happens if a new script is added after my last cookie scan?
It depends on how your banner blocks. An auto-blocker that matches known tracker patterns in the browser holds common trackers straight away, while one that depends on a scan-built list lets the script fire until the next scan. Scan again after every deployment that adds third-party code.
Does changing script type to text/plain affect page speed?
It speeds up the first page load. Blocked scripts do not download or run until consent is given, so the page loads fewer resources. Visitors who reject non-essential cookies never load those scripts at all.
Is a cookie banner without blocking enough under the GDPR?
No. A banner is the visible interface, and the rules apply to what happens behind it. Cookies must be blocked before consent, accepting and rejecting must be equally easy, consent should be logged as proof, and withdrawing must stop the tracking.
How do I block cookies set by embedded YouTube videos?
Move the iframe's src address into a data attribute and assign the iframe a marketing category, so it loads nothing until the visitor consents. Some consent banners do this automatically. The privacy-enhanced youtube-nocookie.com embed reduces tracking but does not remove the need for consent.
Can cookie blocking break my website?
It can if essential scripts are classed as non-essential. Test after every change: chat widgets that fail to load, maps that disappear and blocked payment scripts are the usual signs. Only strictly necessary scripts should run without consent.
Hold every tracker until your visitors choose
If you are not sure which cookies your site sets or whether they wait for consent, start with a scan. Kukie.io lists the cookies and third-party scripts it finds, suggests a category for each and holds known trackers in the visitor's browser until the matching category is accepted.
