yt-dlp: a fork of youtube-dl that still ships monthly

What yt-dlp replaces, and for whom

The README describes yt-dlp as a feature-rich command-line audio/video downloader with support for thousands of sites, and states it is a fork of youtube-dl based on the now inactive youtube-dlc. That lineage explains the project's shape: the interface is a command with flags, the configuration is a file or environment variables, and the output is a media file plus optional metadata sidecars. It is aimed at people who already think in shell commands, cron jobs or Python scripts.

The practical audience is narrower than the download count suggests. If you want a window with a paste box, this is the wrong layer: the repository ships yt-dlp.cmd, yt-dlp.sh and a Makefile, not a desktop application. If you want to fetch a lecture archive nightly, rename files by uploader and date, and skip sponsor segments, the flag surface is already there. The README's table of contents lists Video Selection, Filesystem Options, Post-processing Options and SponsorBlock Options as separate groups, which tells you the project treats each of those as a first-class concern rather than an afterthought.

How the extractor model works

yt-dlp is a dispatcher over extractors. The repository has a yt_dlp/ package directory, and supportedsites.md sits at the top level as the generated list of what those extractors cover. When you hand the tool a URL, it picks an extractor for that site, asks it for the available formats, and then applies your format selection and output template to what comes back. The Makefile exposes a lazy-extractors target, which is the build step that turns the individual extractor modules into a single generated module so startup does not import every site handler.

Two consequences follow. First, site breakage is per extractor, so a fix is a small patch rather than a rewrite of the downloader. Second, the dependency list in pyproject.toml is deliberately thin: the base project declares an empty dependencies array and puts brotli, certifi, mutagen, pycryptodomex, requests, urllib3, websockets and yt-dlp-ejs under an optional default extra. A standalone release binary bundles those; a bare pip install does not, and the README's Dependencies section is where that distinction is spelled out. Plugins are a separate extension path, with Installing Plugins and Developing Plugins as their own README sections.

Installing yt-dlp and running a first download

The README points at three routes: the release binaries, pip, or a third-party package manager, with detailed instructions in the project wiki. The recommended release files are yt-dlp (a platform-independent zipimport binary that needs Python, recommended for Linux/BSD), yt-dlp.exe (Windows 8+ standalone x64, recommended for Windows) and yt-dlp_macos (universal macOS 10.15+ standalone executable). Alternative entries cover musl and aarch64 Linux builds, Windows ARM64, and unpackaged .zip variants that the README marks as having no auto-update.

The README names pip as one of the install routes, and pyproject.toml sets the requires-python floor at 3.10, so the PyPI route is the shortest path on a machine that already has a suitable interpreter. The base install pulls the downloader core; the optional dependencies listed in pyproject.toml, including requests, urllib3, websockets, mutagen and yt-dlp-ejs, live under the default extra, and the README's Dependencies section is where that split is documented.

The README's usage examples are the place to copy commands from, and its Dependencies and Usage and Options sections describe what each flag does. Format selection is documented under Video Format Options and output naming under Output Template, so the two flags you will use first are the ones those sections cover. You should see progress lines for the video and audio streams, then a merge step if ffmpeg is available on PATH. The README also documents a simulation flag for printing the format table without fetching media, under Verbosity and Simulation Options.

For repeat use, the README documents a configuration file and a Notes about environment variables section. Options placed in the config file apply to every invocation, which is how most people stop retyping an output template.

Where yt-dlp breaks or is the wrong choice

The most common failure is not a bug in the downloader; it is a site changing its player. Because each site is handled by its own extractor, a change on one service can break that extractor until a release lands. The dated version scheme exists for exactly this reason: releases are named by date, so you can tell how far behind your installed copy is. A pinned binary from six months ago is a pinned set of extractors from six months ago.

Authentication is the second sharp edge. The README devotes sections to Authentication Options and Authentication with netrc, and the search data shows people asking about cookies from a browser. If a site requires a logged-in session, the tool needs credentials supplied in a supported way, and the documentation is where you check which mechanism applies. Do not assume a URL that works in a browser will work unaided from a script.

The third case is a genuine mismatch of tool to task. If you need a stable, versioned API with guaranteed response shapes for a commercial product, a CLI whose interface is a flag list and whose behaviour tracks upstream sites is a poor foundation. The README documents an Embedding yt-dlp section with examples, so embedding is supported, but the project's own framing is a command-line downloader, not a service. Similarly, if your organisation cannot accept a tool that must be updated frequently to keep working, this is the wrong dependency to take on.

yt-dlp versus youtube-dl

The difference is not features so much as upkeep. youtube-dl is the project yt-dlp forked from, and the README describes youtube-dlc, the intermediate fork, as now inactive. yt-dlp has releases dated 2026.06.09, 2026.07.04 and 2026.08.19, and the last push to the repository was on 2026-08-19, so the codebase is being touched between releases rather than sitting still.

The README keeps a CHANGES FROM YOUTUBE-DL section with subsections for New features, Differences in default behavior and Deprecated options. That last subsection matters more than it looks: if you are migrating existing scripts, some flags you rely on may be deprecated, and some defaults differ. Treat the migration as a config review, not a drop-in binary swap. The other structural difference is the plugin system, which youtube-dl does not have in the same documented form; Plugins and Embedding are both top-level README sections here.

Maintenance cost, licensing and what to verify

The release cadence sets your upgrade cost. Releases arrive roughly monthly, and the last push was on 2026-08-19. Each release can carry extractor fixes, so a sensible policy is to update on a schedule and keep the version visible in your logs. The standalone binaries bundle their dependencies, which makes updating a file replacement; the unpackaged .zip variants in the release table are explicitly marked no auto-update, so those require you to fetch a new archive yourself.

Licensing is straightforward on the surface and worth reading in full. pyproject.toml declares license = "Unlicense" and license-files = ["LICENSE"]. The repository also carries THIRD_PARTY_LICENSES.txt, which is the file to open when you redistribute a bundled binary rather than install from PyPI, because the bundled dependencies are not all under the same terms. Nothing here is legal advice; the two files are the primary sources.

One more operational detail: the README documents a public.key at the repository root, and the release files are the distribution channel. If you fetch binaries in an automated pipeline, that key is part of what you should verify against, and the wiki's installation page is where the project says the detailed steps live.

Editorial conclusion

Adopt yt-dlp if you need a scriptable downloader with format selection, output templates and a plugin system, and you are willing to track its dated releases. Do not adopt it if you want a maintained graphical application; the project ships a CLI, and the GUI search results point at third-party wrappers the README does not cover. Before rolling it out, verify what the Unlicense permits for your redistribution case in THIRD_PARTY_LICENSES.txt, and confirm which release file matches your platform, since the unpackaged .zip variants do not auto-update.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes