Skip to content
PeekWellThe Casebook
Join now

YouTube nocookie: what privacy-enhanced mode does, and what it doesn't

Cheeky, a mint-green founder in a yellow polo shirt and big glasses, stands on a stepladder with a hammer, hanging red curtains on a rail across an old wooden television that shows a plain play triangle. A curtain ring, a tassel and a tin lid fly through the air, and a coffee cup sits on the ladder step.

YouTube nocookie is the everyday name for youtube-nocookie.com, the domain behind YouTube’s privacy-enhanced embed mode. YouTube says the mode keeps views of your embedded video from shaping the viewer’s YouTube recommendations and ads. It doesn’t say the player stores nothing on the visitor’s device or sends nothing to Google. When I tested it, it did both before anyone pressed Play. (If you’re a viewer who landed here: it’s a domain for embeds on other people’s sites, not an ad-free way to watch.)

This guide is for whoever was told “just switch to nocookie” and wants to know if that’s the whole job. It covers what YouTube promises, what a nocookie embed did on my test page, what the EU and UK rules say, and how to build a click-to-load placeholder. Google Maps and Google Fonts have the same problem, so they get a section too.

What is YouTube nocookie? Privacy-enhanced mode in YouTube’s words

YouTube’s help page on embedding videos puts it like this: privacy-enhanced mode prevents the use of views of embedded YouTube content from influencing the viewer’s browsing experience on YouTube. On ads it adds: If ads are served on a video shown in the Privacy Enhanced Mode of the embedded player, those ads will likewise be non-personalized.

Switching it on is a find-and-replace. Copy the code the normal way (Share, then Embed), then follow YouTube’s one instruction: Change the domain for the embed URL in your HTML from https://www.youtube.com to https://www.youtube-nocookie.com. The help page doesn’t describe a checkbox for it, so do it by hand.

<!-- before -->
<iframe src="https://www.youtube.com/embed/VIDEO_ID" ...></iframe>
<!-- after -->
<iframe src="https://www.youtube-nocookie.com/embed/VIDEO_ID" ...></iframe>

The promise also stops at the edge of the frame. If a viewer clicks through to YouTube, that website or app may track the viewer’s behavior as per that website’s or app’s policies and terms.

That’s the full promise: no personalisation of YouTube or of ads from this view. The page says nothing about cookies, local storage or requests to Google. The word “nocookie” lives in the domain name and nowhere in the promise.

What the embed does on your page, before and after Play

I set up a bare test page with one public video on it, using YouTube’s own embed code. I loaded it in a brand-new browser profile (Chromium 153, signed out, nothing stored), read every cookie and storage area, then pressed Play and read them again. Then I ran the same test with the standard youtube.com embed. I ran the nocookie version three times on 26 October 2026 and got the same result each time.

What I looked at youtube-nocookie.com youtube.com
Cookies on load, before Play None Five on youtube.com, four of them set to last about six months
Cookies after Play None The same five
Local storage before Play Two entries The same two
IndexedDB (a browser database) before Play One database Two databases
Google hosts contacted before Play Seven, including a logging call The same set, with youtube.com in place of youtube-nocookie.com, plus two on doubleclick.net, Google’s ad domain
After Play Playback and watch-time statistics sent to youtube-nocookie.com The same, on youtube.com

So the domain swap does something real. The standard embed set five cookies the moment the page opened and called Google’s ad servers without a single click. The nocookie embed set no cookies at all, even after the video played, and made no call to doubleclick.net.

It wasn’t silent, though. Before anyone touched it, the nocookie player wrote two entries to local storage and created an IndexedDB database on the visitor’s device. It loaded a script from www.google.com, fetched the thumbnail from i.ytimg.com and the channel icon from yt3.ggpht.com, and sent a request to an address ending in log_event. Every request carries the visitor’s IP address. When I opened the two storage entries, neither looked like an ID to me: one was a timestamp, the other a note that a database check had worked, set to expire after 30 days. What they’re used for isn’t visible from outside the player. On a laptop, the cookie check guide shows where to find local storage.

Mind the limits: one browser, one country (Greece), one day, signed out. Another browser or a later player might behave differently, so check your own page rather than trust mine.

The rule that matters most here sits next to the GDPR: the cookie rule. Despite its nickname, it covers anything a site stores on the visitor’s device or reads back from it.

In the EU

Article 5(3) of the ePrivacy Directive covers the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user. That’s allowed only with consent, after clear and comprehensive information. The exception is storage or access that’s strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.

The EDPB’s Guidelines 2/2023, adopted in final form on 7 October 2024, spell out how wide that is. Storage includes making use of established protocols such as browser cookie storage as well as customized software (paragraph 36). The rule does not place any upper or lower limit on the length of time that information must persist (paragraph 37), so a small entry counts as much as a big one. Local storage used only inside the device isn’t “access” as long as the information does not leave the device, but once it or anything derived from it is sent off, the rule applies (paragraph 44). The guidelines say plainly that they don’t analyse the exceptions (paragraph 40). They map what’s covered and leave what’s allowed to the exceptions.

In the UK

PECR regulation 6, in the version in force since 5 February 2026, says a person must not store information, or gain access to information stored, in the terminal equipment of a subscriber or user, subject to the exceptions in Schedule A1. One of them is storage strictly necessary for the provision of an information society service requested by the subscriber or user.

The ICO talks about embedded video by name. Its guidance on exceptions says that if you host videos from a platform such as YouTube, you should configure the embedded content not to set storage and access technologies the instant someone visits the page with it on, including for analytics purposes. You should also tell people underneath the embed that pressing Play will use them, and use a privacy mode where one exists. Then: This will not require consent, as the user has been informed and wants to access the content. The alternatives it lists are a consent request in your banner, a just-in-time request on the pages with videos, or links instead of embeds.

The gap between the two

Read the ICO’s words next to my table. The ICO’s no-consent route starts with the embed storing nothing on page load. My nocookie test stored something on page load. Privacy mode is one step in the ICO’s list, not the whole list. The EU text asks whether the visitor “explicitly requested” the service, and a visitor who hasn’t pressed Play hasn’t asked for a video yet. I couldn’t find a regulator decision that names youtube-nocookie either way. Where that leaves an unusual set-up is a question for your lawyer. The click-to-load placeholder below takes it off the table.

In the US

Most US sites have no prior-consent rule for an embed like this. California’s privacy law is the one to watch: it treats passing personal information to a third party for cross-context behavioural advertising as sharing. The US cookie consent guide covers what California asks of a site that shares, and the Video Privacy Protection Act piece covers the lawsuits about video pages and pixels.

Option A: a click-to-load placeholder (the lite YouTube embed pattern)

Show a picture of the video and a play button, both served from your own site. Insert the real iframe only when someone clicks. Until then, nothing from Google is on the page. Paul Irish’s open-source lite-youtube-embed is the best-known version, and it uses youtube-nocookie.com instead of youtube.com in order to be more privacy friendly for end users. One catch: its example sets the poster image from i.ytimg.com, which is YouTube’s image server. Fetching a thumbnail from there is a request to Google. Save the thumbnail and serve it yourself.

A bare version looks like this:

<div class="video" data-id="VIDEO_ID">
  <button type="button" class="video-play">
    <img src="/img/video-poster.jpg" alt="" width="640" height="360">
    <span>Play video: How our kettle works (loads YouTube)</span>
  </button>
  <p class="video-note">Playing this video loads it from YouTube, which stores data on your device. <a href="/cookies/">Cookie policy</a></p>
</div>
<script>
document.querySelectorAll('.video-play').forEach((btn) => {
  btn.addEventListener('click', () => {
    const box = btn.closest('.video');
    const frame = document.createElement('iframe');
    frame.src = 'https://www.youtube-nocookie.com/embed/' + box.dataset.id + '?autoplay=1';
    frame.title = 'YouTube video player';
    frame.allow = 'autoplay; encrypted-media; picture-in-picture';
    frame.allowFullscreen = true;
    frame.width = 640;
    frame.height = 360;
    btn.replaceWith(frame);
  });
});
</script>

Option B: tie the iframe to your banner

If your consent banner can hold an iframe back until a category is accepted, you can use that. If you go this way, the ICO wants the banner to say that accepting may result in the video sharing platform collecting information about their viewing (eg for analytics and advertising purposes), and people who say no should see links to the videos instead. Then test it, because some set-ups block scripts and let iframes straight through. Consent mode won’t do it for you: Google’s list of supported tags doesn’t include YouTube embeds.

Option C: host the video yourself

A video file on your own server avoids YouTube altogether. You trade YouTube’s free bandwidth for your own bill.

The line next to the player

Whichever you pick, put one sentence under the player saying that playing loads the video from YouTube, with a link to your cookie policy. That’s the ICO’s “tell the user underneath the embed” step.

Build order

  1. List every page with a video on it. Search your site’s code for youtube.com/embed and youtube-nocookie.com.
  2. Switch each one to youtube-nocookie.com. It’s the smallest step and it drops the cookies and the ad calls.
  3. Replace each embed with a placeholder, or put it behind the banner’s consent.
  4. Save the thumbnails and serve them from your own site.
  5. Add the line under each player.
  6. Update the cookie policy and the list of recipients in your privacy notice to name YouTube.
  7. Check again on a phone, with the steps at the end of this guide.

Or hand the job to an assistant:

Here is the HTML of a page on my site: [paste]. Find every YouTube, Vimeo and Google Maps iframe. Replace each one with a click-to-load placeholder: a real <button> element with a text label, a self-hosted thumbnail image I'll supply, and one short line of text under it saying that playing loads content from [provider], with a link to /cookies/. Only insert the real iframe after the visitor clicks, and use youtube-nocookie.com for YouTube. Keep it keyboard accessible: the button must be reachable with Tab and work with Enter and Space, and focus should move to the player after it loads. Give me the HTML, the CSS and a small script with no outside libraries.

Keep the keyboard part in. A placeholder that only works with a mouse locks some visitors out of your video.

Google Maps, Google Fonts and other embeds

Google Fonts and the GDPR

Fonts loaded from Google’s servers send each visitor’s IP address, the page address and browser details to Google, says Google’s own Fonts FAQ. Google says it does not use any information collected by Google Fonts to create profiles of end users or for targeted advertising.

A German court still found a problem with it. On 20 January 2022 the Munich Regional Court (Landgericht München I, case 3 O 17493/20) ruled on a site that passed a visitor’s IP address to Google through Google Fonts without consent. It ordered the site to stop, to tell the visitor what data it held, and to pay €100 in damages under Article 82 GDPR. On legitimate interest it was short: the fonts could be used without the visitor’s browser connecting to Google at all. It’s one regional court’s judgment in one case, not an EU-wide ruling.

The UK takes a softer line. The ICO puts an external font library under its appearance exception, warns that such libraries may collect information about your users, such as their IP address, and says you then must explain it and offer a simple, free way to object. It also says You could consider self-hosting fonts.

Self-hosting is the fix in both places. Google’s FAQ says so itself: When a font is loaded from the website operator’s servers, Google does not receive any kind of data related to the visits to the website.

Google Maps and the GDPR

I ran the same test on a Google Maps embed. It set no cookies and stored nothing in my run, but it made 37 requests to Google hosts before I touched it. Each one carries the visitor’s IP address, which is the Munich font question again, 37 times over. The simple fixes: a plain map image you’re allowed to use, with a link that opens Google Maps, or the same click-to-load placeholder as the video.

Vimeo and other video hosts

Vimeo has a dnt player parameter. Vimeo’s player parameters page says setting it to true blocks the player from collecting session data and analytics, that it’s off by default, and that With DNT active, some essential cookies will still be active. Vimeo’s nocookie, then, with the same limit. The placeholder works for any host.

Common mistakes on real sites

  • Switching the domain and stopping there. It’s a good first step and a poor last one.
  • A placeholder that fetches its thumbnail from Google. The iframe waits, but the picture already called i.ytimg.com. Serve the image yourself.
  • Banner categories that hold back scripts but not iframes. If the YouTube logo shows while the banner is still unanswered, the frame loaded.
  • “www.youtube-nocookie.com refused to connect.” That’s the browser blocking the frame. If your site sends a Content-Security-Policy, its frame-src list says which sites may appear in your iframes, and a list that names youtube.com but not youtube-nocookie.com blocks the new embed. In my test it did. The other common cause is a /watch?v= address in the code instead of /embed/. YouTube’s watch pages refuse to be framed by other sites, on either domain. The security headers guide covers frame-src.
  • A placeholder that’s a div with a click handler. It looks the same, but a keyboard can’t reach it. Use a real button.
  • An old embed in a blog post nobody remembers. The homepage gets fixed; a 2019 post keeps the youtube.com player and its cookies.

Check your own site with a phone

You don’t need a tool for this.

  1. Open a private tab, so nothing you accepted before gets in the way.
  2. Load a page with a video and don’t touch the banner. If you see YouTube’s title bar and logo, the real player is already there. If you see your own picture and button, the placeholder is waiting.
  3. Tap the padlock or site information icon, then the cookies or site data entry. Note which sites already appear. youtube.com or youtube-nocookie.com before you’ve done anything means the player loaded early.
  4. Tap Reject, reload, and look again. Nothing from YouTube should appear until you press Play.
  5. On Android, type view-source: in front of the page address. Search the code for youtube.com/embed. Any hit is an embed that still uses the standard domain.
  6. Do the same on your contact page for Google Maps, and search the code for fonts.googleapis.com.

Peeky reads your public pages the way a first-time visitor’s phone opens them, and writes down what loads and what gets stored before the visitor chooses. For trackers and storage before consent, the check is EU-01 in the EU and UK-01 in the UK. For advertising cookies that load before a UK visitor has answered the banner, it’s UK-05.

Questions people ask

Is YouTube nocookie GDPR compliant?

Not on its own. YouTube's help page promises that views in privacy-enhanced mode won't shape the viewer's YouTube experience or ads. It says nothing about storage on the device. In my own test the player wrote to local storage and contacted seven Google hosts before anyone pressed Play. The EU rule on device storage asks for consent unless it's strictly necessary, so a click-to-load placeholder is the safer route.

Is youtube-nocookie safe?

It's a real Google domain, the one YouTube's help page tells you to use for privacy-enhanced mode, so you're not dealing with a scam or a mirror. It's also gentler than the standard embed: in my test the youtube.com player set five cookies on load and the nocookie one set none. It still loads YouTube's player, stores a little data and talks to Google before Play.

Does youtube-nocookie remove ads?

No. It changes how ads are picked, not whether they show. YouTube's help page says that if ads are served on a video in privacy-enhanced mode, those ads will be non-personalised, and the view won't be used to personalise ads elsewhere. If you're a viewer hoping for ad-free playback, look elsewhere: this domain is built for sites that embed videos.

Why does www.youtube-nocookie.com say refused to connect?

Usually a rule is blocking the frame. The common causes: your site's Content-Security-Policy has a frame-src list that names youtube.com but not youtube-nocookie.com; the code points at a /watch address, which YouTube won't let other sites frame, instead of /embed/; or a firewall or browser extension blocks the domain. YouTube's help page tells network admins to allowlist youtube-nocookie.com.

Do I need consent for Google Fonts?

If the fonts load from Google's servers, every visitor's IP address goes to Google. In January 2022 the Munich Regional Court ordered a site owner to stop doing that without consent and pay the visitor €100. In the UK, the ICO wants an explanation and a free way to object. Self-hosting removes the question: Google says it then receives nothing.

Filed with