A blank YouTube embed already phoned home
Drop the standard <iframe> from YouTube's share dialog onto a page, load it, and open your network tab. Before the visitor clicks anything, the browser has already connected to youtube.com and googlevideo.com, requested resources from Google, and written entries to local storage under the embed's origin. That request carries the visitor's IP address to Google. Under Article 5(3) of the ePrivacy Directive, storing or reading information on a user's device needs consent unless it is strictly necessary for a service the user asked for. A marketing video autoloading in the background is not that.
So the question is not whether you can embed video. It is how to stop the embed from doing anything until the visitor has agreed. Two half-measures get recommended constantly, and both are worth understanding before you rely on them.
What youtube-nocookie actually does
Google offers a "privacy-enhanced mode" served from youtube-nocookie.com. The name oversells it. In privacy-enhanced mode, YouTube holds back some cookies until the visitor plays the video, but it does not sit quietly on load. The embed still writes identifiers like yt-remote-device-id to local storage the moment the page renders, and it still sends the visitor's IP to Google to fetch the player. The second someone presses play, cookies get set whether or not consent was given.
There is a second trap here. Clicking a play button is not, by itself, valid consent. France's regulator, the CNIL, has been clear that a bare click on play does not meet the GDPR bar of freely given, specific, informed, and unambiguous agreement. The visitor has to be told what will happen (this content loads from YouTube and sets cookies) and then choose to proceed. A play button with no notice attached is just a play button.
Use youtube-nocookie.com as the destination once you do load the player. Treat it as a reduction in cookies, not a consent exemption.
What Vimeo's dnt=1 actually does
Vimeo gives you a cleaner switch. Add ?dnt=1 to the player URL and Vimeo will not set new tracking cookies during that session. Per Vimeo's own player-cookies documentation, with DNT on the only cookies set are ones it treats as essential to running the player securely (player_clearance, cf_clearance, _cf_bm, _cfuvid), and the player loses conveniences like remembering volume, quality, and caption preferences.
That is genuinely better than a default YouTube embed, but two things remain true. First, dnt=1 does not stop cookies that were already stored from a previous Vimeo visit from being sent. Second, Vimeo is a US company, so loading the player still transfers the visitor's IP and request data to the United States. If your legal basis strategy treats US transfers as consent-gated, the dnt=1 player still belongs behind a consent gate. It lowers the cookie footprint; it does not remove the third-party connection.
The pattern that actually works: click-to-load
The reliable approach for both platforms is a facade. You render a lightweight placeholder (a static thumbnail plus a play control) that sets nothing and connects nowhere. Only when the visitor clicks, having been told what loading involves, do you inject the real iframe. The click is the affirmative act, and the notice makes it informed.
Here is a minimal, dependency-free version:
<div class="yt-facade" data-video-id="VIDEO_ID">
<button type="button" class="yt-facade__play"
aria-label="Play video. Loads YouTube and sets cookies.">
<img src="/thumbs/my-video.jpg" alt="Video: product walkthrough" loading="lazy">
</button>
</div>
document.querySelectorAll('.yt-facade').forEach((el) => {
el.querySelector('.yt-facade__play').addEventListener('click', () => {
const iframe = document.createElement('iframe');
iframe.src = 'https://www.youtube-nocookie.com/embed/'
+ el.dataset.videoId + '?autoplay=1';
iframe.title = 'YouTube video player';
iframe.allow = 'autoplay; encrypted-media; fullscreen';
iframe.setAttribute('allowfullscreen', '');
el.replaceChildren(iframe);
});
});
The same shape works for Vimeo, pointing the injected iframe at https://player.vimeo.com/video/VIDEO_ID?dnt=1&autoplay=1. Paul Irish's open-source lite-youtube-embed web component packages this facade pattern with proper keyboard and accessibility handling if you would rather not hand-roll it. As a bonus, a facade loads far less JavaScript up front, so it helps your Largest Contentful Paint instead of hurting it. See our guide on banners and Core Web Vitals for why that matters.
Wiring the gate to your consent state
A pure click-to-load facade treats the click as consent for that one video. That is defensible for a video the user deliberately chooses to watch. If you would rather drive embeds from your central consent categories instead, mark the iframe so it stays inert until the matching category is granted, and let your consent platform swap it in:
<iframe
data-src="https://www.youtube-nocookie.com/embed/VIDEO_ID"
data-consent-category="marketing"
src="about:blank"
title="YouTube video player"></iframe>
The key is that src is harmless until consent lands, at which point the platform copies data-src into src. This is exactly the mechanism a consent management platform like CookieBeam uses to hold third-party scripts and iframes before consent, and its scanner reports the outbound connections each embed opens (to youtube.com, googlevideo.com, or player.vimeo.com) so you know which embeds need gating in the first place. If you drive gating from categories rather than per-click, back it up with server-side enforcement so a client-side bypass cannot leak the load.
A short checklist
- No video iframe loads on page render. A facade or a gated
about:blankiframe stands in until consent. - When you do load YouTube, point at
youtube-nocookie.comto trim the cookie set, but never treat that domain as a consent exemption. - For Vimeo, append
?dnt=1, and still gate the player because of the US transfer. - Tell the visitor what loading the embed does before they click. A bare play button is not informed consent.
- Scan the live page and confirm no connection to a video host fires before consent.
Video is one of the most common reasons a site that "has a cookie banner" still leaks data before consent. The fix is small, it improves performance, and it takes the embed out of your compliance risk. Social posts and maps have the same problem and the same cure, covered in our guides on social embeds and Google Maps.