YouTube Broke 200,000 GitHub Stars: Why yt-dlp Now Needs an Entire JavaScript Engine Just to Save a Video
---
title: "YouTube Broke 200,000 GitHub Stars: Why yt-dlp Now Needs an Entire JavaScript Engine Just to Save a Video"
published: true
description: "yt-dlp swapped its homemade Python JS interpreter for Deno. Now Deno has an end date and Bun got capped for going vibe-coded."
tags: opensource, python, javascript, discuss
cover_image: opengraph.githubassets.com
---
To save a YouTube video in 2026, yt-dlp, a video downloader with over 200,000 stars on GitHub, has to start a whole separate JavaScript engine on your computer. Without one, its YouTube support is officially "deprecated." The engine it picked as the safe default is Deno, and last month Deno's makers announced that they're joining Cloudflare and will stop developing the runtime after one more year. Another option, Bun, got frozen at its last pre-rewrite version in May because yt-dlp's maintainers think it has gone "fully vibe-coded."
{% github yt-dlp/yt-dlp %}
I haven't run any of this. I read yt-dlp's source and its issue tracker instead, and the code tells the story better than the announcements do.
The record labels went after this exact trick
In 2020 the RIAA sent GitHub a takedown notice against youtube-dl, yt-dlp's parent project. Its complaint was specific. The code, it said, gets around YouTube's "rolling cipher," and the project's own sample downloads included Taylor Swift's "Shake It Off." GitHub pulled the repo, then put it back a few weeks later.
The yt-dlp repo went up three days after that notice. Today it has over 60,000 more stars than youtube-dl, which hasn't tagged a release since 2021, and it inherited the same problem the lawyers had put their finger on.
Remember that phrase, rolling cipher. It's still the whole fight.
For years it faked JavaScript in Python
Here's the cipher in plain terms. When you press play, YouTube's player script scrambles a couple of values in the video's URL: a signature, and a parameter the community calls n. Ask for the stream without doing that scrambling yourself and you get throttled to a crawl, or an HTTP 403. So any downloader has to run YouTube's own JavaScript, and there's no shortcut, because the scrambling code is rewritten and re-obfuscated every time Google ships a new version of its player.
yt-dlp is a Python program. Its answer, for years, was to write a JavaScript interpreter in Python, almost a thousand lines of it. The heart of it is a table that maps JavaScript operators onto Python ones:
_OPERATORS = { # None => Defined in JSInterpreter._operator
'?': None,
'??': None,
'|': _js_bit_op(operator.or_),
'===': operator.is_,
'==': _js_eq_op(operator.eq),
'>>': _js_bit_op(operator.rshift),
'+': _js_arith_op(operator.add),
'%': _js_mod,
'**': _js_exp,
# …
}
Every bitwise operation goes through a helper that squeezes Python's unlimited integers back into JavaScript's signed 32 bits. It's a careful little imitation of a whole programming language, built by volunteers for one purpose: running a single obfuscated function that Google's engineers keep rewriting. One Hacker News commenter called it "a brilliant hack but limited in capability."
Limited is putting it kindly.
The maintainers had to find YouTube's functions with regex before they could interpret them. In the announcement that ended this approach, maintainer bashonly described what every player change cost them:
> Any time YouTube changed something about their player JS, it would cause multiple maintainers to drop everything and spend all of their free time for the next 2-3 days trying to fix things.
Then YouTube spread those functions all over the player, and the same post estimates the old method would now eat "2-3 weeks" of maintainers' free time per breakage. So last year yt-dlp gave up and started handing the job to a real JavaScript runtime, with a solver kept in a separate repo.
The engine it trusted is about to lose its developers
Why not just use Node, you might ask?
Safety. The solver executes code fetched from Google's servers, on the machines of what the maintainers call their "less-technically-inclined users." Deno blocks file and network access by default. You can see the paranoia in the provider code, which starts Deno with --no-remote, --no-prompt and --no-config and feeds it the script through standard input. Deno is the only runtime switched on by default; Node, Bun and QuickJS stay off unless you pass a flag to opt in yourself.
Then, last month, Deno's makers announced they were joining Cloudflare:
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
A user opened an issue the same day asking yt-dlp to plan for a new default. It's still open. Node isn't an easy swap: in that thread, one participant argues its permission sandbox is "still not hardened enough."
Bun is worse off. In May the maintainers capped it, and the reason is the most-reacted issue in the repo's history:
> Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded.
They meant it. The Bun provider hard-codes version 1.3.14 as "the last supported bun version" and refuses to run anything newer.
What changes for you
If you've ever pasted a link into yt-dlp and gotten a 403, this fight is usually somewhere behind it. The official binaries bundle the solver. If you installed with pip, you need the yt-dlp[default] extra plus Deno somewhere on your PATH, and if you got it from Homebrew or a Linux package manager, it depends on how your packager decided to split things up. Skip the runtime and the maintainers say plainly that your YouTube formats will keep shrinking, and that this "will not be considered a 'bug' but rather an inevitability."
The other sites are fine.
yt-dlp ships more than 1,700 extractors, and almost none of them need JavaScript. This is a YouTube problem. It's also the problem that keeps landing on Hacker News, where three threads about it have each pulled in more than 600 comments.
The real threat isn't Google
Think about where that leaves a Python project with a public-domain license and a strict no-AI contribution policy. Its YouTube support now rests on runtimes it doesn't control, and of the five it supports, one is losing its developers, one is frozen at an old version, and the obvious replacement fails the same safety test that picked Deno in the first place.
That's not a long list.
The maintainers once wrote that switching to a headless browser "would be an admission of defeat." Years of YouTube changes never got them there.
The JavaScript ecosystem might do it in one.
Mentions
YouTube Broke 200,000 GitHub Stars: Why yt-dlp Now Needs an Entire JavaScript Engine Just to Save a Video --- title: "YouTube Broke 200,000 GitHub Stars: Why yt-dlp Now Needs an Entire JavaScript Engine Just to Save a Video" published: true description: "yt-dlp swapped its homemade Python JS interpreter for Deno. Now Deno has an end date and Bun got capped for going vibe-coded." tags: opensource, python, javascript, discuss cover_image: opengraph.githubassets.com --- To save a YouTube video in 2026, yt-dlp, a video downloader with over 200,000 stars on GitHub, has to start a whole separate JavaScript engine on your computer. Without one, its YouTube support is officially "deprecated." The engine it picked as the safe default is Deno, and last month Deno's makers announced that they're joining Cloudflare and will stop developing the runtime after one more year. Another option, Bun, got frozen at its last pre-rewrite version in May because yt-dlp's maintainers think it has gone "fully vibe-coded." {% github yt-dlp/yt-dlp %} I haven't run any of this. I read yt-dlp's source and its issue tracker instead, and the code tells the story better than the announcements do. The record labels went after this exact trick In 2020 the RIAA sent GitHub a takedown notice against youtube-dl, yt-dlp's parent project. Its complaint was specific. The code, it said, gets around YouTube's "rolling cipher," and the project's own sample downloads included Taylor Swift's "Shake It Off." GitHub pulled the repo, then put it back a few weeks later. The yt-dlp repo went up three days after that notice. Today it has over 60,000 more stars than youtube-dl, which hasn't tagged a release since 2021, and it inherited the same problem the lawyers had put their finger on. Remember that phrase, rolling cipher. It's still the whole fight. For years it faked JavaScript in Python Here's the cipher in plain terms. When you press play, YouTube's player script scrambles a couple of values in the video's URL: a signature, and a parameter the community calls n. Ask for the stream without doing that scrambling yourself and you get throttled to a crawl, or an HTTP 403. So any downloader has to run YouTube's own JavaScript, and there's no shortcut, because the scrambling code is rewritten and re-obfuscated every time Google ships a new version of its player. yt-dlp is a Python program. Its answer, for years, was to write a JavaScript interpreter in Python, almost a thousand lines of it. The heart of it is a table that maps JavaScript operators onto Python ones: _OPERATORS = { # None => Defined in JSInterpreter._operator '?': None, '??': None, '|': _js_bit_op(operator.or_), '===': operator.is_, '==': _js_eq_op(operator.eq), '>>': _js_bit_op(operator.rshift), '+': _js_arith_op(operator.add), '%': _js_mod, '**': _js_exp, # … } Every bitwise operation goes through a helper that squeezes Python's unlimited integers back into JavaScript's signed 32 bits. It's a careful little imitation of a whole programming language, built by volunteers for one purpose: running a single obfuscated function that Google's engineers keep rewriting. One Hacker News commenter called it "a brilliant hack but limited in capability." Limited is putting it kindly. The maintainers had to find YouTube's functions with regex before they could interpret them. In the announcement that ended this approach, maintainer bashonly described what every player change cost them: > Any time YouTube changed something about their player JS, it would cause multiple maintainers to drop everything and spend all of their free time for the next 2-3 days trying to fix things. Then YouTube spread those functions all over the player, and the same post estimates the old method would now eat "2-3 weeks" of maintainers' free time per breakage. So last year yt-dlp gave up and started handing the job to a real JavaScript runtime, with a solver kept in a separate repo. The engine it trusted is about to lose its developers Why not just use Node, you might ask? Safety. The solver executes code fetched from Google's servers, on the machines of what the maintainers call their "less-technically-inclined users." Deno blocks file and network access by default. You can see the paranoia in the provider code, which starts Deno with --no-remote, --no-prompt and --no-config and feeds it the script through standard input. Deno is the only runtime switched on by default; Node, Bun and QuickJS stay off unless you pass a flag to opt in yourself. Then, last month, Deno's makers announced they were joining Cloudflare: > We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. A user opened an issue the same day asking yt-dlp to plan for a new default. It's still open. Node isn't an easy swap: in that thread, one participant argues its permission sandbox is "still not hardened enough." Bun is worse off. In May the maintainers capped it, and the reason is the most-reacted issue in the repo's history: > Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded. They meant it. The Bun provider hard-codes version 1.3.14 as "the last supported bun version" and refuses to run anything newer. What changes for you If you've ever pasted a link into yt-dlp and gotten a 403, this fight is usually somewhere behind it. The official binaries bundle the solver. If you installed with pip, you need the yt-dlp[default] extra plus Deno somewhere on your PATH, and if you got it from Homebrew or a Linux package manager, it depends on how your packager decided to split things up. Skip the runtime and the maintainers say plainly that your YouTube formats will keep shrinking, and that this "will not be considered a 'bug' but rather an inevitability." The other sites are fine. yt-dlp ships more than 1,700 extractors, and almost none of them need JavaScript. This is a YouTube problem. It's also the problem that keeps landing on Hacker News, where three threads about it have each pulled in more than 600 comments. The real threat isn't Google Think about where that leaves a Python project with a public-domain license and a strict no-AI contribution policy. Its YouTube support now rests on runtimes it doesn't control, and of the five it supports, one is losing its developers, one is frozen at an old version, and the obvious replacement fails the same safety test that picked Deno in the first place. That's not a long list. The maintainers once wrote that switching to a headless browser "would be an admission of defeat." Years of YouTube changes never got them there. The JavaScript ecosystem might do it in one.