yt-dlp: the most useful tool in my workflow, and it has nothing to do with AI
Every video that ends up in my notes passes through one command-line program first. Why the cheapest mode is the one where you don't download the video at all, where it breaks, and what I had to settle in my own head about the legal side.
Most of the things I save these days — videos, talks, courses — go through a single program as step one. There is no AI in it. It has no web interface. It is called yt-dlp, and it is a command-line tool that downloads video and audio from the web.
Lately there have been quite a few Instagram reels doing the rounds along the lines of "the most useful tool on GitHub that nobody shows you". The numbers in them hold up better than I expected — but a few things are stated more loosely than they should be. So I checked, and wrote down how I actually use it.
What the claims get right
"Over 180,000 stars on GitHub." True. As of 12 August 2026 it has 183,998. That puts it among the most-starred repositories in existence.
"Public domain, nobody owns it." Almost. The licence is The Unlicense, which opens with the line "This is free and unencumbered software released into the public domain." So "released into the public domain" is a fair description. It is only "nobody owns it" that is rhetorically neat and legally vague — in some jurisdictions, Germany for instance, you cannot waive copyright at all. That is exactly why the Unlicense also carries a fallback permissive licence and a warranty disclaimer, rather than relying on the dedication alone. For practical purposes: it does not get much less restricted than this.
"It downloads a whole playlist with one command." True, and simpler than they make it sound — no flag is needed for a playlist. You just hand it the playlist URL and it takes the lot. The flags exist for the opposite case: --no-playlist, for when you want only the single video behind a link that points at both.
"Video with the audio included." By default, yes — that corresponds to -f bestvideo*+bestaudio/best. The catch that no reel mentions: you need ffmpeg to merge the video and audio. Without it, yt-dlp quietly falls back to a single pre-muxed stream, which is usually lower quality. Nothing shouts about it; you simply end up with a worse file.
The mode I use most: don't download the video at all
This is the part nobody shows in those reels, and for my purposes it is the most useful thing yt-dlp does.
When I am saving notes from a video, I don't need the video. I need the transcript. And on YouTube that usually already exists — either from the creator or auto-generated.
So this is the combination I run more or less constantly:
yt-dlp --skip-download --write-sub --write-auto-sub --sub-lang en --sub-format vtt <URL>
--skip-download means not a single byte of video comes down. All you get is the subtitle file. No gigabytes, no disk space, no transcription bill.
That is the distinction worth remembering: if you are feeding YouTube videos into a speech-to-text service, check first whether the subtitles already exist. Most of the time they do. Free, instant, and where they are human-written, more accurate than ASR.
Alongside them I grab the metadata:
| Flag | What I get |
|---|---|
--write-sub | Subtitles written by the video's creator |
--write-auto-sub | Auto-generated subtitles, when the above don't exist |
--write-info-json | Metadata: title, channel, duration, date, view counts |
--skip-download | No media is downloaded at all |
One practical detail I ran into: auto-generated subtitles repeat the same lines over and over. YouTube's VTT is full of duplicates because every line gets redrawn. Before you pass it on, it is worth stripping the timestamps, the <...> tags and consecutive identical lines. Skip that and you are processing roughly three times more text than you need to.
Where it breaks
Thousands of sites are supported, and YouTube, TikTok, X and Twitch all work. But not every extractor is in the same shape, and the maintainers say so themselves in the list.
Instagram is the weakest. The main extractor isn't flagged as broken, but instagram:user — the one for profiles — carries a "(Currently broken)" note. Instagram also has by far the most open issues, including missing audio on reels with music, plus recurring trouble with cookies and rate limits. In practice: for Instagram you need cookies from your browser, and every so often it simply stops working. I use gallery-dl for that myself these days; it handles posts, carousels and reels in one pass more reliably.
For TikTok it is the secondary extractors that are flagged as broken (tiktok:effect, tiktok:sound, tiktok:tag); the main one is fine. The extractor for X is still called twitter internally.
The general rule that follows: an extractor is a dependency on somebody else's HTML, and it can break on any given Tuesday. If something that has to keep running depends on it, it needs monitoring and a plan for the week it falls over.
youtube-dl versus yt-dlp
A small note, because I still come across guides recommending the former. yt-dlp is a fork of youtube-dl (by way of youtube-dlc). The difference in practice: youtube-dl hasn't shipped a release since December 2021, whereas yt-dlp put out version 2026.07.04 last month and takes commits continuously. If a guide tells you to "install youtube-dl", it is four and a half years old.
The legal part the reels leave out
I didn't want to skip this, because it gets sidestepped fairly systematically.
Downloading from YouTube breaches their terms — except through the features YouTube offers for it itself, such as offline mode in Premium. It isn't a crime, it is a contractual matter, but it is a real condition, and "the tool is legal" doesn't address it. Instagram, TikTok and X have comparable bans on automated access.
The history is worth knowing too. On 23 October 2020 the RIAA sent GitHub a takedown under §1201 of the DMCA (circumvention of technical measures) aimed at youtube-dl, and GitHub took the repository down, forks included, within about a day. The EFF then wrote to GitHub explaining why the circumvention argument was wrong, and on 16 November 2020 GitHub reinstated the repository — along with a developer defence fund and a reworked process for §1201. yt-dlp was still too young to be a target at the time, but it inherits the same legal reasoning.
How I handle it, in three rules:
- My own content, licensed content, public domain or Creative Commons. That covers the vast majority of what I actually need it for.
- Cookies from a logged-in account only for things I legitimately have access to — and never to reach something non-public. That is where the line runs between a grey area and something indefensible.
- Downloading something does not grant you rights to it. Transcribing somebody else's video for my own notes is a different thing from republishing that material. The tool is neutral; the use isn't.
Why I'm writing about this at all
Because that reel was right about one thing, though not the thing it was emphasising: the most useful tool in my AI workflow is a tool with no AI in it.
The whole clever part — summarising, note-taking, searching through it all — only works once the input is on disk and in text form. And the boring part that puts it there is still the same command-line program that nobody puts on a slide.
Verified on 12 August 2026 against primary sources: the yt-dlp repository (star count via the GitHub API), LICENSE, the supported sites list, release history, the RIAA takedown, the EFF on the repository's reinstatement. Star and issue counts change; take them as of the verification date. This text is not legal advice.