The claim that Google secretly wants YouTube downloaders to work doesn't hold up. Their focus is on delivering videos across a vast range of devices without breaking playback(and even that is blurring[0]), not enabling downloads.
If you dive into the yt-dlp source code, you see the insane complexity of calculations needed to download a video. There is code to handle nsig checks, internal YouTube API quirks, and constant obfuscation that makes it a nightmare(and the maintainers heroes) to keep up. Google frequently rejects download attempts, blocks certain devices or access methods, and breaks techniques that yt-dlp relies on.
Half the battle is working around attempts by Google to make ads unblockable, and the other half is working around their attempts to shut down downloaders. The idea of a "gray market ecosystem" they tacitly approve ignores how aggressively they tweak their systems to make downloading as unreliable as possible. If Google wanted downloaders to thrive, they wouldn't make developers jump through these hoops. Just look at the yt-dlp issue tracker overflowing with reports of broken functionality. There are no secret nods, handshakes, or other winks, as Google begins to care less and less about compatibility, the doors will close. For example, there is already a secret header used for authenticating that you are using the Google version of Chrome browser [1] [2] that will probably be expanded.
The argument the article is making is that if they really wanted YouTube downloaders to stop working, they'd switch to Encrypted Media Extensions. Do you think that's not plausible?
Many smart devices that have youtube functionality(tvs, refrigerators, consoles, cable boxes, etc), have limited or no ability to support that functionality in hardware, or even if they do, it might not be exposed.
Once those devices get phased out, it is very likely they will move to Encrypted Media Extensions or something similar, I believe I saw an issue ticket on yt-dlp's repo indicating they are already experimenting with such, as certain formats are DRM protected. Lookup all the stuff going on with SABR which if I remember right is either related to DRM or what they may use to support DRM.
> Google needs YouTube downloaders. They perform a valuable role: If it were impossible to download YouTube videos, many organizations would abandon hosting their videos on YouTube for a platform that offered more user flexibility. Or they’d need to host a separate download link and put it in their YouTube descriptions. But organizations don’t need to jump through hoops -- they just let people use YouTube downloaders.
I don't think I believe this, as much as I'd like to. How many organizations would really consider this a critical need? My guess is, not enough for Google to care.
> Google has now covered its tracks better -- there’s nothing about “Google Product Abuse” in its current AdSense policies.
In other (less biased) words: These old rules were rescinded haven't been enforced since 2012 (last example cited). This article was written in 2025 and still complaining about something that isn't happening anymore.
The article doesn't include Android TV based devices like Chrome/Fire sticks. Android mobile apps tend not to work with remote controls. The best Android TV app is: https://smarttubeapp.github.io/
ytarchive is also great for downloading livestreams.
Unfortunately, it's not as up-to-date as yt-dlp so it can be fragile against blocks. I'm hoping that yt-dlp adds some functionality for downloading portions of a livestream (i.e. not downloading from the start, 120 hours ago).
Huh, last/only time I used yt-dlp on a livestream it downloaded exactly from when I ran it, didn't get anything in the past at all (which was a shame for me personally at the time, as I would have liked the earlier stuff too).
Maybe that was a difference in the stream itself though, since I've experienced both past-seekable and live-only live streams on YouTube.
turning off the DVR is just a UI change. ytarchive can still grab the past parts of the broadcast just fine. What's really funny is it will even download censored segments which sometimes happens in music broadcasts like A State Of Trance or Group Therapy. You can also force enable seeking with a userscript if you wish.
The problem with this DVR feature is that if your connection is stuttering it will buffer you backwards a bit. Streamers like to disable this because they want to keep the time to deliver as low as possible so chat is more interactive and engaging, especially on youtube where your viewership might not qualify for the CCV metrics if the stream is not in a foreground tab. Best to leave it off if that is important for you.
Youtube is a youtube downloader. Everything is a downloader. It's literally impossible to interact with a thing without downloading it and having the data. The difference is that the data is usually deleted later (a silly practice done to trick the lawyers into believing the world is like they think it is, hiding actual reality that would confuse and enrage them).
Agreed, more or less, but I would argue you could make a distinction for a "streaming" situation where say no more than 10% of the data is on your computer at any one point in time, vs "downloading" where the data exists in its entirety at once.
You could encode these terms in a contract or something about allowed usage of a service, I believe.
Even with DRM, if you can see it, it's decoded somewhere along the line. There will always be a way to get the raw video out of it if you're committed enough.
That's actually an important distinction. You can recapture the DRM protected (and then decoded) video pretty much always indeed, but then you degrade the quality by having to encode it again.
Well, not important to some, but for enthusiasts and people looking to actually archive things, it is very important.
Case in point, hilariously, the last time I used YouTube's video download feature bundled with their Premium offering, I got a way worse quality output than with yt-dlp, which actually ripped the original stream without reencoding it.
I think I saw an idempotent h264 encoder at some point, where you wouldn't suffer generational loss if you matched the encoder settings exactly from run to run. But then you might need the people mastering the content (in this case YouTube) to adopt that same encoder, which they're not going to be "interested" in.
The claim that Google secretly wants YouTube downloaders to work doesn't hold up. Their focus is on delivering videos across a vast range of devices without breaking playback(and even that is blurring[0]), not enabling downloads.
If you dive into the yt-dlp source code, you see the insane complexity of calculations needed to download a video. There is code to handle nsig checks, internal YouTube API quirks, and constant obfuscation that makes it a nightmare(and the maintainers heroes) to keep up. Google frequently rejects download attempts, blocks certain devices or access methods, and breaks techniques that yt-dlp relies on.
Half the battle is working around attempts by Google to make ads unblockable, and the other half is working around their attempts to shut down downloaders. The idea of a "gray market ecosystem" they tacitly approve ignores how aggressively they tweak their systems to make downloading as unreliable as possible. If Google wanted downloaders to thrive, they wouldn't make developers jump through these hoops. Just look at the yt-dlp issue tracker overflowing with reports of broken functionality. There are no secret nods, handshakes, or other winks, as Google begins to care less and less about compatibility, the doors will close. For example, there is already a secret header used for authenticating that you are using the Google version of Chrome browser [1] [2] that will probably be expanded.
[0] Ask HN: Does anyone else notice YouTube causing 100% CPU usage and stattering? https://news.ycombinator.com/item?id=45301499
[1] Chrome's hidden X-Browser-Validation header reverse engineered https://news.ycombinator.com/item?id=44527739
[2] https://github.com/dsekz/chrome-x-browser-validation-header
The argument the article is making is that if they really wanted YouTube downloaders to stop working, they'd switch to Encrypted Media Extensions. Do you think that's not plausible?
Many smart devices that have youtube functionality(tvs, refrigerators, consoles, cable boxes, etc), have limited or no ability to support that functionality in hardware, or even if they do, it might not be exposed.
Once those devices get phased out, it is very likely they will move to Encrypted Media Extensions or something similar, I believe I saw an issue ticket on yt-dlp's repo indicating they are already experimenting with such, as certain formats are DRM protected. Lookup all the stuff going on with SABR which if I remember right is either related to DRM or what they may use to support DRM.
> Google needs YouTube downloaders. They perform a valuable role: If it were impossible to download YouTube videos, many organizations would abandon hosting their videos on YouTube for a platform that offered more user flexibility. Or they’d need to host a separate download link and put it in their YouTube descriptions. But organizations don’t need to jump through hoops -- they just let people use YouTube downloaders.
I don't think I believe this, as much as I'd like to. How many organizations would really consider this a critical need? My guess is, not enough for Google to care.
Also, if you upload a video to YouTube you can download it from YouTube Studio at any time, so that doesn't add up at all.
YouTube just doesn't make this available via API, but you've always been able to manually from YouTube Studio download your uploaded videos.
> Google has now covered its tracks better -- there’s nothing about “Google Product Abuse” in its current AdSense policies.
In other (less biased) words: These old rules were rescinded haven't been enforced since 2012 (last example cited). This article was written in 2025 and still complaining about something that isn't happening anymore.
The article doesn't include Android TV based devices like Chrome/Fire sticks. Android mobile apps tend not to work with remote controls. The best Android TV app is: https://smarttubeapp.github.io/
> The best YouTube downloader for Android is NewPipe. You should have a look at Tubular, a fork.
I just started using Tubular. The built-in SponsorBlock integration is really nice
It's interesting that YouTube not only does not block pirated movies on ok.ru, they give them high rankings in search. Hm.
ytarchive is also great for downloading livestreams.
Unfortunately, it's not as up-to-date as yt-dlp so it can be fragile against blocks. I'm hoping that yt-dlp adds some functionality for downloading portions of a livestream (i.e. not downloading from the start, 120 hours ago).
Huh, last/only time I used yt-dlp on a livestream it downloaded exactly from when I ran it, didn't get anything in the past at all (which was a shame for me personally at the time, as I would have liked the earlier stuff too).
Maybe that was a difference in the stream itself though, since I've experienced both past-seekable and live-only live streams on YouTube.
turning off the DVR is just a UI change. ytarchive can still grab the past parts of the broadcast just fine. What's really funny is it will even download censored segments which sometimes happens in music broadcasts like A State Of Trance or Group Therapy. You can also force enable seeking with a userscript if you wish.
The problem with this DVR feature is that if your connection is stuttering it will buffer you backwards a bit. Streamers like to disable this because they want to keep the time to deliver as low as possible so chat is more interactive and engaging, especially on youtube where your viewership might not qualify for the CCV metrics if the stream is not in a foreground tab. Best to leave it off if that is important for you.
https://greasyfork.org/en/scripts/485020-ytbetter-enable-rew...
Not sure if this applies to livestreams but look into the --download-sections arg?
yt-dlp --download-sections "*05:00-05:10" <YouTube URL>
Doesn’t work for livestreams as far as I know. There’s an open PR: https://github.com/yt-dlp/yt-dlp/pull/6498
Is Stacher open source?
Last time I searched 'stacher open source' on Google, I found a Reddit thread discussing when it might become open source.
EDIT: The reason I ask is that the article says Stacher is open source, and that is news to me.
TIL about stacher!Thank you.
Yeah! Stacher was one of the reasons I shared this on HN.
Also interesting take on why downloaders are ethical; Google tacitly allows and actually needs them.
“The best downloaded for iOS/ipados” is yt-dlp. Install in ashell, view with VLC.
Youtube is a youtube downloader. Everything is a downloader. It's literally impossible to interact with a thing without downloading it and having the data. The difference is that the data is usually deleted later (a silly practice done to trick the lawyers into believing the world is like they think it is, hiding actual reality that would confuse and enrage them).
Agreed, more or less, but I would argue you could make a distinction for a "streaming" situation where say no more than 10% of the data is on your computer at any one point in time, vs "downloading" where the data exists in its entirety at once.
You could encode these terms in a contract or something about allowed usage of a service, I believe.
You could. But youtube's website itself would fail this "only 10% at once" test.
Why? IIRC you can flush the SourceBuffer in Media Source Extention and only keep a small part of the video in the browser's RAM at all time.
(It won't work for Youtube shorts though, because 10% of a 30s video just isn't enough for reliable smooth playback)
Unless it’s protected by DRM.
Even with DRM, if you can see it, it's decoded somewhere along the line. There will always be a way to get the raw video out of it if you're committed enough.
That's actually an important distinction. You can recapture the DRM protected (and then decoded) video pretty much always indeed, but then you degrade the quality by having to encode it again.
Well, not important to some, but for enthusiasts and people looking to actually archive things, it is very important.
Case in point, hilariously, the last time I used YouTube's video download feature bundled with their Premium offering, I got a way worse quality output than with yt-dlp, which actually ripped the original stream without reencoding it.
I think I saw an idempotent h264 encoder at some point, where you wouldn't suffer generational loss if you matched the encoder settings exactly from run to run. But then you might need the people mastering the content (in this case YouTube) to adopt that same encoder, which they're not going to be "interested" in.
Even with DRM video you can fetch it losslessly. At some point, some part of your system requires access to the raw, decrypted video stream.
As long as that's the case, you can get bit-perfect netflix rips.
Downloading videos is a premium feature of YouTube and doesn't delete the data.
Can you access those downloads?