Every content-processing pipeline has an unglamorous first step: getting the media onto a machine where you can process it. Transcription, summarisation, clip generation, competitive research, archiving — all of it starts with a file, and none of the impressive parts work until that file exists.
For a large share of the industry, that first step is one program: yt-dlp. It is a command-line video downloader, it has no AI in it whatsoever, and it is probably the most widely deployed piece of software nobody puts on a slide.
We use it in production. Here is the honest assessment — including the parts that should stop you deploying it on client work without a conversation first.
What it is, precisely
yt-dlp is a command-line program that extracts video and audio from websites. As of 12 August 2026 it has 183,998 stars on GitHub, which puts it among the most-starred repositories in existence.
Its lineage is two steps, not one. The README is explicit: yt-dlp is a fork of youtube-dl based on the now-inactive youtube-dlc. That matters for a practical reason — youtube-dl itself has not shipped a release since December 2021, while yt-dlp released version 2026.07.04 last month and had commits to master as recently as 4 August 2026. If a tutorial tells you to install youtube-dl, it is more than four years out of date.
The licence question
A claim circulating about yt-dlp is that it is "public domain — nobody owns it." That is a fair plain-English gloss but worth stating precisely, because licence questions are the kind of thing that surfaces during procurement.
The LICENSE file is The Unlicense, which opens: "This is free and unencumbered software released into the public domain." So the accurate sentence is "released under the Unlicense, a public-domain dedication" — not "unlicensed" and not "MIT."
The nuance worth knowing: several jurisdictions, Germany among them, do not permit an author to abandon copyright at all. This is precisely why the Unlicense carries a permissive fallback grant and a warranty disclaimer rather than relying on the dedication alone. For commercial use the practical answer is that it is about as unencumbered as software gets. "Nobody owns it" is rhetorically fine and legally loose.
What it actually does
The capability that surprises people is that the defaults are already what you want. The default format selection is equivalent to -f bestvideo*+bestaudio/best — best video and best audio, muxed together. There is no flag to remember.
Two caveats attach to that default and both cause support tickets:
- Merging separate video and audio streams requires ffmpeg to be installed. Without it, yt-dlp silently falls back to a single pre-muxed stream, which is usually lower quality.
- The same fallback applies when streaming to stdout.
Playlists need no special handling either: point it at a playlist URL and it downloads the whole playlist. The flags that exist are the opposite controls — --no-playlist to grab only the single video when a URL refers to both, and --playlist-items 1-5 to take a range.
For pipeline work, the flags that matter are the ones that pull everything except the video:
| Flag | What you get | Why it matters in a pipeline |
|---|---|---|
| --write-subs | Publisher-provided subtitle file | Free, accurate transcript — no ASR cost at all |
| --write-auto-subs | Auto-generated (ASR) captions | Fallback when no human subtitles exist |
| --write-info-json | Full metadata as JSON | Title, uploader, duration, view and like counts |
| --skip-download | Metadata and subtitles only, no media | The cheapest mode, and the one most people miss |
That last combination is the genuinely useful trick for anyone building summarisation or research workflows. You frequently do not need the video at all. --skip-download --write-subs --write-auto-subs fetches the transcript and nothing else — no gigabytes, no storage, no transcription bill. If your AI pipeline is paying for speech-to-text on YouTube content, check whether captions already exist first.
Where it breaks
The supported-sites list runs to thousands of extractors, and YouTube, TikTok, X and Twitch all work. But not every extractor is equal, and the maintainers say so in the list itself.
Instagram is the weak point. The main extractor is not officially flagged as broken, but instagram:user — the profile extractor — carries a "(Currently broken)" marker, and Instagram accounts for the largest cluster of open issues, including missing audio on music reels and recurring cookie and rate-limit failures. In practice Instagram requires browser cookies and breaks periodically. Plan for it rather than discovering it.
Some TikTok sub-extractors (tiktok:effect, tiktok:sound, tiktok:tag) are also marked broken, while the main TikTok extractor is fine. The X extractor is still named twitter internally.
The operational consequence: an extractor is a dependency on someone else's private HTML, and it can break on any Tuesday. If a client-facing process depends on one, it needs monitoring and a defined answer for the week it stops working. This is the same failure mode as any scraping dependency, and it should be budgeted as ongoing maintenance rather than a one-off build.
The legal position, stated plainly
This is the section that matters commercially, and it is the one every enthusiastic tutorial omits.
Downloading from YouTube violates YouTube's Terms of Service except through features YouTube provides, such as Premium offline viewing. That is contract law rather than criminal law, and the exposure is the user's, but it is a real term and "the tool is legal" does not dispose of it. Instagram, TikTok and X have comparable prohibitions on automated access.
The history is instructive. On 23 October 2020 the RIAA sent GitHub a DMCA §1201 anti-circumvention takedown against youtube-dl, and GitHub disabled the repository and its forks within about a day. The EFF wrote to GitHub rebutting the circumvention theory, and GitHub reinstated the repository on 16 November 2020, alongside a developer defence fund and a revised §1201 review process. yt-dlp was too young to be the target, but it inherits the same legal theory.
Three rules we apply, and recommend:
- Content you own, content licensed to you, or public-domain and Creative Commons material. That covers the overwhelming majority of legitimate business use — your own webinars, your own channel archive, licensed footage.
- Never use logged-in cookies to reach private content. Fetching something behind an account you were given access to for a different purpose is a materially worse problem than a ToS breach, and it is the line that turns a grey area into an indefensible one.
- Downloading does not confer rights. Transcribing a competitor's video for internal research sits differently from republishing their footage. The tool is neutral; the use is not.
Should this be in your stack?
A short test:
- Are you paying for transcription of content that already has captions? Then yes, immediately — this is pure cost removal with no legal complication if the content is yours.
- Are you archiving your own published media? Yes. This is the cleanest use case there is, and platform export tools are consistently worse.
- Are you building a client-facing feature on top of it? Slow down. You are taking on an extractor that can break, a ToS question that belongs in the contract, and a support burden. Sometimes correct — but it is a decision, not a detail.
- Are you scraping third-party content at scale to republish or train on? That is a legal conversation, not a tooling one, and the answer is not in this article.
Frequently asked questions
Is yt-dlp free for commercial use? Yes. It is released under the Unlicense, a public-domain dedication with a permissive fallback for jurisdictions that do not recognise abandonment of copyright. There is no commercial restriction in the licence.
What is the difference between yt-dlp and youtube-dl? yt-dlp is a fork with substantially more features, faster downloads and far more maintained extractors. youtube-dl has not had a release since December 2021. Use yt-dlp.
Do I need ffmpeg? For best quality, yes — the highest video and audio streams are served separately and must be merged. Without ffmpeg you get a lower-quality pre-muxed file, silently.
Can it get transcripts without downloading video?
Yes, and this is its most underrated use. Combining --skip-download with the subtitle flags retrieves captions and metadata alone, which is dramatically cheaper than downloading media and running speech-to-text.
Is using it legal? The software is lawful and its licence is unrestricted. Using it against a platform whose terms prohibit downloading breaches those terms, and downloading copyrighted material you have no rights to may infringe regardless of the tool. Keep it to your own content, licensed content, or openly licensed material.
Verified 12 August 2026 against primary sources: yt-dlp repository (star count via GitHub API), LICENSE, supported sites list, release history, RIAA takedown notice, EFF on the reinstatement. Star counts and issue volumes move; treat them as accurate to the verification date. Nothing here is legal advice.
