The Best Youtube Downloaders, and How Google Silenced the Press
Key topics
The article discusses the best YouTube downloaders and how Google has silenced the press by allegedly using its advertising monopoly to bully publications into not discussing software Google doesn't like, sparking a heated debate among commenters about the ethics and implications of YouTube downloading.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
4h
Peak period
57
12-24h
Avg / period
20
Based on 160 loaded comments
Key moments
- 01Story posted
Sep 19, 2025 at 8:20 AM EDT
4 months ago
Step 01 - 02First comment
Sep 19, 2025 at 12:15 PM EDT
4h after posting
Step 02 - 03Peak activity
57 comments in 12-24h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 26, 2025 at 5:23 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Also interesting take on why downloaders are ethical; Google tacitly allows and actually needs them.
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.
As long as that's the case, you can get bit-perfect netflix rips.
Even DRM media is using regular accelerated video decode.
That is not what we're talking about - the working assumption here is that the DRM scheme is sound and effective. In which case your only possible but also guaranteed stage of recapture is at the analog hole, by which point the media encoding is already undone, incurring a generational loss.
[0] I consider presently existing and historical DRM implementations deeply flawed and misguided; they severely overstep their boundaries implied by the name "DRM", in certain cases quite disgustingly - hence the many added adjectives for clarification
[1] puzzlingly, any access control will actually get you in the same legal situation, regardless of whether the access control mechanism is effective or sound, so this is actually a design decision; but it's pretty universally taken afaik.
Lol. That is not possible.
If I'm able to watch something, my device must be able to decrypt the DRM. If my device can decrypt the DRM, I can take my device apart and figure out how it does this, and do it myself.
The most DRM encumbered format is DCP, used my cinemas. Each projector has a unique key burnt into it, the decryption, decoding and watermarking happen on the same piece of silicon, and the entire device is built like an HSM, opening it wipes the keys.
There are bit-perfect DCP rips on the high seas, with the original compressed data.
HDCP is meant to prevent me from copying HDMI signals. Every conference center and lecture hall has cheap Chinese devices that remove it.
Regarding the analog hole, with a properly calibrated professional video camera recording in RAW, with both camera and monitor genlocked and color calibrated, and the proper postprocessing, you can capure the original pixel values exactly.
I've done that part more often than I'd like...
And worst case, you can then brute force which parameters the original encode used to re-encode your data without generation loss.
It is possible, both under the conservative interpretation of the word (like how AACS is continuously updated as security holes are found and compromises happen, with the keys being rotated each time), and on a theoretical level (FHE). The latter is not being done because it is not nearly performant enough, and the former is an ongoing cat and mouse game that is once again irrelevant to what we were discussing here.
With FHE, the "take the machine apart and analyze what it does to get the original bitstream" would be cryptographically hard, so good luck with that. With the usual DRM schemes it isn't, so they are pretty much always cracked in a few months or a few years, but until that point they are both sound and effective.
> Regarding the analog hole, with a properly calibrated professional video camera recording in RAW, with both camera and monitor genlocked and color calibrated, and the proper postprocessing, you can capure the original pixel values exactly.
Yes, that's what I'm suggesting too...
> And worst case, you can then brute force which parameters the original encode used to re-encode your data without generation loss.
Can you? I mean in practice, in a practical amount of time. And is that actually done?
You could encode these terms in a contract or something about allowed usage of a service, I believe.
(It won't work for Youtube shorts though, because 10% of a 30s video just isn't enough for reliable smooth playback)
Yes, it could. It'd only just waste more bandwidth having to redownload and cause more pauses. But people who buy things (the important ones to advertise to) have fast connections and everyone's locked in so google can focus more on advertiser issues over the lower end network user experience.
https://support.google.com/youtube/answer/11977233
And a static mp4 file encoded with ffmpeg -movflags +faststart -start_at_zero can be seeked within in any browser from any static webserver and viewed at any seeking time without downloading the rest. Is this streaming too?
Given the first example of fully watching and the second implementation of streaming with a simple static file you can see the streaming/file download distinction you make is much thinner than it first appears. At least from a technical perspective.
In lawyer-ese you are making a valid semantic point which I do acknowledge. "Streaming" in lawyer-ese means a corporation is doing it so there's: 1. legal liability 2. lots of abstraction layers involved so they don't get upset and 3. the local files are hidden from view of the user. Unlike the simple streaming example with a properly encoded .mp4 file.
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).
yt-dlp --download-sections "*05:00-05:10" <YouTube URL>
Maybe that was a difference in the stream itself though, since I've experienced both past-seekable and live-only live streams on YouTube.
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...
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.
You should also look at PipePipe, also available on F-Droid and with similar enhancements (e.g., Sponsorblock) over NewPipe.
https://github.com/InfinityLoop1308/PipePipe
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.
YouTube just doesn't make this available via API, but you've always been able to manually from YouTube Studio download your uploaded videos.
I hope your “surely” was in jest.
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
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.
It's much more likely YouTube just doesn't want to mess with it's caching apparatus unless it really has to. And I think they will eventually, but the numbers just don't quite add up yet.
> If you choose to upload Content, you must not submit to the Service any Content that does not comply with this Agreement (including the YouTube Community Guidelines) or the law. For example, the Content you submit must not include third-party intellectual property (such as copyrighted material) unless you have permission from that party or are otherwise legally entitled to do so. [...]
> By providing Content to the Service, you grant to YouTube a worldwide, non-exclusive, royalty-free, sublicensable and transferable license to use that Content (including to reproduce, distribute, prepare derivative works, display and perform it) in connection with the Service and YouTube's (and its successors' and Affiliates') business, including for the purpose of promoting and redistributing part or all of the Service.
If you include others' work with anything stronger than CC0, that's not a license you can grant. So you'll always be in trouble in principle, regardless of whether or how YouTube decides to exercise that license. In practice, I wouldn't be surprised if the copyright owner could get away with a takedown if they wanted to.
[0] https://www.youtube.com/t/terms#27dc3bf5d9
To date, many Creative Commons licenses do in fact amount to "permission from that party", but if they start using DRM, those licenses would cease to grant YouTube permission.
> No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
(https://creativecommons.org/licenses/by-sa/4.0/legalcode.en)
Most of the CC licenses include such language and have since the first versions.
Wrong question leads to the wrong answer.
The right one is "how much of the ad revenue would be lost if". For now it's cheaper to spend bazillions on a whack-a-mole.
> 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.
No, organizations simply use YouTube because it's free, extremely convenient, has been very stable enough over the past couple decades to depend on, and the organization does not have the resources to setup an alternative.
Also, I'm guessing such organizations represent a vanishly small segment of YouTube's uploaders.
I don't think people appreciate how much YouTube has created a market. "Youtuber" is a valid (if often derided) job these days, where creators can earn a living wage and maintain whole media companies. Preserving that monetization portal is key to YouTube and its content creators.
Can confirm at least one tech news website argued this point and tore down their own video hosting servers in favor of using Youtube links/embeds. Old videos on tweakers.net are simply not accessible anymore, that content is gone now
This was well after HTML5 was widely supported. As a website owner myself, I don't understand what's so hard now that we can write 1 HTML tag and have an embedded video on the page. They made it sound like they need to employ an expensive developer to continuously work on improving this and fixing bugs whereas from my POV you're pretty much there with running ffmpeg at a few quality settings upon uploading (there are maybe 3 articles with a video per day, so any old server can handle this) and having a quality selector below the video. Can't imagine what about this would have changed in the past decade in a way that requires extra development work. At most you re-evaluate every 5 years which quality levels ffmpeg should generate and change an integer in a config file...
Alas, little as I understand it, this tiny amount of extra effort, even when the development and setup work is already in the past(!), is apparently indeed a driving force in centralizing to Youtube for for-profits
You acknowledge that it's not that simple:
> running ffmpeg at a few quality settings upon uploading (there are maybe 3 articles with a video per day, so any old server can handle this)
Can any old server really handle that? And can it handle the resulting storage of not only the highest-quality copy but also all the other copies added on top? My $5 Linode ("any old server") does not have the storage space for that. You can switch your argument to "storage is cheap these days," but now you're telling people to upgrade their servers and not actually claiming it's a one-click process anymore.
I use Vimeo as a CDN and pay $240 per year for it ($20/month, 4x more than I spend on the Linode that hosts a dozen different websites). If Vimeo were to shut down tomorrow, I'd be pretty out of luck finding anyone offering pricing even close to that-- for example, ScaleEngine charges a minimum of $25 per month and doesn't even include storage and bandwidth in their account fee. Dailymotion Pro offers a similar service to Vimeo these days, but their $9/month plan wouldn't have enough storage for my catalog, and their next cheapest price is $84/month. If you actually go to build out your own solution with professional hosting, it's not gonna be a whole lot cheaper.
Obviously, large corporations can probably afford to do their own hosting-- and if push came to shove, many of them probably would, or would find one of those more expensive partner options. But again, you're no longer arguing "it's just an HTML tag." You're now arguing they should spend hundreds or thousands per year on something that may be incidental to their business.
The server is $30/month hosted by OVH, which comes with 2TB of storage. The throughout on the dedicated server is 1gbps. Unlimited transfer is included (and I've gone through many dozens of TB of traffic in a month).
Bandwidth these days can be less than .25/m at a 100g commit in US/EU, and OVH is pushing dozens of tb/s.
Big ups on keeping independent.
It’s a trade off I suppose - you can very well host your own streaming solution, and for the same price you can get a great single node, but if you want good TTFB and nodes with close proximity to many regions you may as well pay for a managed solution as the price for multiple VPS/VM stacks up quickly when you have a low budget
Edit: I think I missed your point about bandwidth pricing lol, but the second still stands
Could be a lot cheaper and less need for global distribution if low latency weren't a requirement. And by low latency I mean the video stream you watch is ~2s behind reality just like Youtube, Twitch, Kick, etc. If your use case is VOD or can tolerate 10s latency streaming, single PoP works fine.
The point is that if I chose Vimeo or AWS/GCP/Azure for this, at their bandwidth pricing my (in my opinion modest) usage would be costing tens of thousands of dollars monthly, which it most certainly does not.
Managed service pricing and the perception of it needs to change, because it feels like a sham once you actually do anything yourself.
Y'all just have two different budgets. For one person $30 / mo is reasonable for the other it's expensive.
But the core claim, that $5 / mo hosts a lot of non-video content but not much video content, holds.
But yeah okay, not any server variant can do this and the cloud premium is real. You'd need so spend like 5€/month on real hard drives if you want, say, 4TB of video storage on top of your existing website (the vimeo and dailymotion price points mentioned suggest that their catalogue is above 1 but below 2 TB). The 5€/month estimate is based on the currently most-viewed 4TB hard drive model in the tweakers pricewatch (some 100€), a modest average longevity of 5 years, triple redundancy, and that you would otherwise be running on smaller drives anyway for your normal website and images so there's no (significant) additional labor or electricity costs for storage (as in, you just buy a different variant of the same setup, not need to install additional ones)
A $28/mo (Australian) vimeo subscription, or the "Advanced" $91/mo plan include the same 2TB bandwidth/month for viewers of your videos.
If you upload a 100MB video and it gets 20000 views the whole way through, you are now in the "contact sales" category of pricing.
This is why Youtube has a monopoly, because you've been badly tricked into thinking this pricing is fair and that 2TB is in any way shape or form adequate.
Does it handle buffer?
And, theres plenty of tutorials on using ffmpeg based tools to make the files. And yes, "oh no, I need to learn something new for my video workflow."
That's rude and uncalled for. I didn't say I was unwilling to learn something new. I said the economics don't work out for the solution someone else proposed. And I also disputed the statement, "we can write 1 HTML tag and have an embedded video on the page." Now you've moved the goalpost to "learn something new" (which actually means "design and deploy an entire new system").
Reddit struggles to provide a video player that is up to YouTube’s par. Do you have more resources than Reddit? Better programmers?
Reddit and Youtube have just a massive number of people visiting and trying to watch video at all time. It requires an enormous amount of bandwidth to serve up that video.
Youtube goes through heroic efforts to make videos instantly available and to apply high quality compression on videos that become popular.
If you don't have a huge viewership or dynamic content then yeah, it's actually pretty easy to setup and run videos sites (infowars has managed it). Target h264 and aac audio with a set number of resolutions and bitrates and viola, you've got something that's pretty competitive on the cheap that can play on pretty much any device.
It's not optimal for bandwidth, for that you need to start sniffing client capabilities. However, it'll get the job done while being pretty much universally playable.
Do they put a different amount of compression effort in if the video isn't (expected to become) popular?
I'd not be shocked if they do more aggressive compression for well known creators.
For nobodies (like myself) the compression is very basic. Whatever I send ends up compressed with VP9 which, I believe, youtube has a bunch of hardware that can do that really fast.
> Reddit struggles to provide a video player that is up to YouTube’s par. Do you have more resources than Reddit? Better programmers?
It's hard to say whether MDN and I have/am better programmer(s) and resource(s) than reddit without having any examples or notions of what issues reddit has run into.
If you mean achieving feature-parity, like automatic subtitles and dubbing and control menus to select languages and format those subtitles etc., that's a whole different ball game of course. The site I was speaking of doesn't support that today either (they don't dub/sub), at best you get automatically generated Dutch subtitles from yt now, i.e. shit subtitles (worse than English autogen and we all know how well those deal with jargon and noise)
I can't speak to Dutch websites but in the U.S., a news website will usually feel obligated to provide subtitles on their videos to avoid lawsuits under the ADA.
As for that video being small and not receiving thousands of simultaneous views: sure, but buying sufficient bandwidth is not a "hire better programmers" problem. You don't need to beat Reddit's skills and resources to provide smoother video playback. Probably the opposite actually: smaller scale should be easier to handle than reddit scale, and they already had that all set up
But even if they did - I don't see why Google would care about these organizations. I expect anyone doing this is not expecting to get any views from the algorithm, is not bringing in many views or monetizing their videos.
To steelman it though, maybe Google cares if their monopoly benefits from nobody even knowing other video sites exist.
Looking closely, at least for yt-dlp, you would see it tries multiple methods to grab available formats, tabulates the working ones, and picks from them. Those methods are constantly being peeled away, though some are occasionally added or fixed. The net trend is clear. The ability to download is eroding. There have been moments when you might seriously consider that downloading, at least without a complicated setup(PO-Tokens, widevine keys, or something else), is just going to stop working.
As time goes on, even for those rare times you want to grab a video, direct downloading may no longer work. You might have to resort to other methods, like screen recording through software or an actual camera, for as long as your devices will let you do even that.
I very rarely download YouTube videos but simply having done it a few times over the years, and even watching the text fly by in the terminal with yt-dlp, everything you’ve said is obvious.
Screen recording indeed might fail—Apple lets devs block it, so even screen recording the iPhone Mirroring app can result in an all-black recording.
How long until YouTube only plays on authorized devices with screens optimized for anti-camera recording? Silver lining, could birth a new creative industry of storytelling, like courtroom sketch artists with more Mr. Beast.
Well, how about thanks the people who's maintaining the downloader to make it possible?
> they haven't made it impossible to download videos, so that is a win IMO.
At some point you can just fire up OBS Studio and do a screen rip, then cut the ads out manually and put it on Torrent/ED2k.
Will you still think it's a win then?
A lot of the reason for that is because yt-dlp explicitly makes it easy for you to update it, so I would imagine that many frontends will do so automatically - something which is becoming more necessary as time goes on, as YouTube and yt-dip play cat and mouse with each other.
Unfortunately, lately, yt-dip has had to disable by default the downloading of certain formats that it was formerly able to access by pretending to be the YouTube iOS client, because they were erroring too often. There are alternatives, of course, but those ones were pretty good.
A lot of what you see in yt-dlp is because of the immense amount of work that the developers put in in order to keep it working. Despite that it now allows for downloading from many more sites than it originally was developed for, they're still not going to give up YouTube support (as long as it still allows DRM-free versions) without a fight.
Once YouTube moves to completely DRM'd videos, however, that may have to be when yt-dlp retires support for YouTube, because yt-dlp very deliberately does not bypass DRM. I'd imagine the name would change at that point.
This just made me incredibly grateful for the people who do this kind of work. I have no idea who writes all the uBlock Origin filters either, but blessed be the angels, long may their stay in heaven be.
I'm pretty confident I could figure it out eventually but let's be honest, the chance that I'd ever actually invest that much time and energy is approximates zero close enough that we can just say it's flat nil.
Maybe Santa Claus needs to make some donations tonight. ho ho ho
This is quite different from websites monetizing traffic through and trackers placed on their own webpages. Those can still be reliably blocked by preventing websites from loading third party content.
Im glad I wasn't blocked or throttled, but it seems like it'd be trivial to block someone like me
Am I missing something? It does sort of feel like they're allowing it
EDIT: Spooky skeletons.. Youtube suddenly as of today forces a "Sign in to confirm you’re not a bot" on both the website and yt-dl .. So maybe I've been fingerprinted and blacklisted somehow
Youtube does try to throttle the data speeds, when that first happened, youtube-dl stopped being useful and everyone upgraded their python versions and started using yt-dlp instead.
Don’t forget - most “content creators” are not technical - self hosting is not an option.
And even if it were - it costs money.
The concern is likely that if they let it become too easy the small minority becomes a large majority and the ad business becomes unsustainable.
Consider the ease and adoption of newsgroups in the early 90s vs Napster/Limewire later and the effect that had on revenues.
To buy premium to support creators.
Once yt becomes hostile the deal between me and yt is off.
Or is it something different you are thinking about?
What benefits does DRM even provide for public, ad-supported content that you don't need to log for in order to watch it?
Does DRM cryptography offer solutions against ad blocking, or downloading videos you have legitimate access to?
Sorry that I'm too lazy to research this, but I'd appreciate if you elaborate more on this.
And also, I think they're playing the long game and will be fine to put up a login wall and aggressively block scraping and also force ID. Like Instagram.
Would be glad if I'm wrong, but I don't think so. They just haven't reached a sufficient level of monopolization for this and at the same time, the number of people watching YouTube without at least being logged in is probably already dwindling.
So they're not waiting anymore to be profitable, they already are, through ads and data collection.
But they have plenty of headroom left to truly start boiling the frog, and become a closed platform.
And ever updating with that!
Google needs to be broken up already.
Indeed the complexity is insane
https://news.ycombinator.com/item?id=45256043
But what is meant by "a video". Is this referring to the common case or an edge/corner case. Does "a" mean one particular video or all videos
"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."
True, but is this code required for all YouTube videos
The majority of YT videos are non-commercial, unpromoted with low view counts. These are simple to download
For example, the current yt-dlp project contains approximately 218 YT IDs. A 2024 version contained approximately 201 YT IDs. These are often for testing edge cases
The example 1,525-character shell script below outputs download URLs for almost all the YT IDs found in yt-dlp. No Python needed
By comparison the yt-dlp project is 15,679,182 characters, approximately
The curl binary is used in the example only because it's popular, not because I use it. I use simpler, more flexible software than curl
I have been using tiny shell script to download YT videos for over 15 years. I have been downloading videos from googlevideo.com for even longer, before Google acquired YouTube.^1 Surprisingly (or not), when YT changes something that requires updating the script (and this has only happened to me about 5 times or less in 15 years) I have generally been able to fix the shell script faster than yt-dl(p) fixes its Python program (same for NewPipe/NewPipeSB)
I prefer non-commercial videos that are not promoted. The ones with relatively low view counts. For more popular videos, I listen to the audio file first before downloading the video file. After listening to the audio, I may decide to skip the video. Also I am not overly concerned about throttling
1. The original Google Video made a distinction between commercial and non-commercial(free) videos. The later were always easy to download, and no sign-in/log-in was required. This might be a more plausible theory why YT has always allowed downloads for non-commercial videos
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.
For Linux... youtube-dl I guess, because there's still no really nice alternative to it. It doesn't seem like Stacher supports non-debian systems, or non-gnu libc systems, either.
I'd advise against downloading via someone else's servers anyway, as can be seen by their instance being blocked by Google. Hopefully some day someone manages to port yt-dlp to WASM, then it can be run locally in the browser without needing a download.
Fun fact: yt-dlp is public domain! That's really generous of them and I'm really thankful for their work.
The efforts at DRM done by companies like Netflix is done because the companies that licensed the content demand it. That doesn't mean the DRM works. You can find torrents of all those shows.
Granted, you would have to deal with whatever your display does to the raw video signal - preferable to pointing a camcorder at the display but a little worse than the original file.
Causation does not mean correlation. The vast majority of content available via torrents did not come from breaking a streamer's DRM.
83 more comments available on Hacker News