Skip to content

Start typing. Errors match on their exact yt-dlp output.

↑ ↓ to move, ↵ to open esc to close

yt-dlp: pip, pipx, Binary or Nightly — Which to Install

Tested on yt-dlp 2026.07.28 Updated

Quick answer

The choice looks like packaging and is really about latency: how many days pass between a fix being written and it reaching you. On a tool whose job is tracking sites that change weekly, that number decides how often yt-dlp appears broken. Shortest path first:

binary, nightly channel — fixes within a day 
yt-dlp --update-to nightly

The comparison

MethodFix latencyUpdate withNeeds Python
Binary, nightlyHours to a dayyt-dlp -UNo
Binary, stableDays to weeksyt-dlp -UNo
pip / pipx, pre-releaseHours to a daypipx upgradeYes
pip / pipx, stableDays to weekspipx upgradeYes
HomebrewDaysbrew upgradeNo
Rolling distroDaysSystem updateNo
Frozen distroMonths to neverSystem updateNo

Everything else about these is a rounding error. The bottom row is the one that generates most of the support questions on the internet.

Why latency is the whole question

yt-dlp is not a program that reaches a finished state. It reads pages whose structure belongs to someone else, and when that structure changes the program stops working until someone reads the new one. Fixes are frequent and small.

So "how old is your build" is the first question behind nsig extraction failed, unable to extract player response, missing formats, and downloads that cap at 360p. It is not a coincidence that "update it" is the first step on nearly every error page on this site.

The standalone binary

One file with Python bundled inside, and the only method where yt-dlp can replace itself:

Linux 
sudo curl -L https://github.com/yt-dlp/yt-dlp/releases/latest/download/yt-dlp -o /usr/local/bin/yt-dlp
sudo chmod a+rx /usr/local/bin/yt-dlp
Windows 
winget install yt-dlp.yt-dlp
macOS 
sudo curl -L https://github.com/yt-dlp/yt-dlp/releases/latest/download/yt-dlp_macos -o /usr/local/bin/yt-dlp
sudo chmod a+rx /usr/local/bin/yt-dlp

It also carries its own certificate bundle, which sidesteps most of the certificate problems that pip installs run into.

The cost: -U writes over the file, so a system-wide install needs root to update. Installing to ~/.local/bin avoids that.

pip and pipx

Right when you are calling yt-dlp from Python code rather than from a shell — you get the library as well as the command:

bash 
pipx install yt-dlp
pipx upgrade yt-dlp
inside your own virtualenv 
pip install -U "yt-dlp[default]"

Use pipx rather than bare pip for the command-line tool. Modern Linux distributions block pip from writing into system Python — the externally-managed-environment error — and pipx is the supported answer.

Stable and nightly

Two channels. Stable is tagged periodically; nightly is built once a day from master.

bash 
yt-dlp --update-to nightly
yt-dlp --update-to stable
yt-dlp --update-to 2026.07.28
pip equivalent 
pip install -U --pre "yt-dlp[default]"

Nightly sounds risky and mostly is not: master is gated by tests and review, and the difference between it and a release is usually a handful of extractor fixes. Weigh that against the failure mode of stable, which is a working tool sitting behind a fix that already exists.

Rolling back is one command, which is what makes nightly a reasonable default rather than a gamble.

Which build for which situation

  • Occasional personal use. Whatever your OS makes easy — winget, Homebrew, your package manager if it is rolling. Update when something breaks.
  • Regular use. The binary on the nightly channel. You will notice breakage within a day and get the fix within one.
  • A scheduled job. Binary, nightly, and update before each run. A cron job on a stale build fails silently for weeks.
  • Calling it from Python. pipx or a virtualenv, so you have the library too.
  • A container. Install in the Dockerfile and rebuild regularly — the Docker guide covers making that automatic.

Updating in a scheduled job

Cheap insurance. || true so a failed update does not abort the whole run:

bash 
#!/bin/sh
/usr/local/bin/yt-dlp -U --update-to nightly || true
/usr/local/bin/yt-dlp --download-archive /srv/archive.txt -i "CHANNEL_URL"

Checking what you have

bash 
yt-dlp --version
which -a yt-dlp

The version is a date. Two paths from which -a means two installs, and PATH order decides which one runs — the usual explanation for "I updated and nothing changed".

Frequently asked

Is nightly actually risky?
Less than the name suggests. Nightly is built from master, which is gated by a test suite and reviewed changes. In practice the risk of running a build from yesterday is smaller than the risk of running one from six weeks ago while YouTube has changed twice.
How do I go back if a nightly breaks something?
yt-dlp --update-to stable returns you to the release channel, and --update-to 2026.07.28 pins an exact version. Rolling back takes one command, which is most of why nightly is a reasonable default.
Does the binary need Python installed?
No. The standalone builds bundle a Python runtime. That is why they are around 15 MB rather than a few hundred kilobytes, and why they work on machines with no Python at all.
Which is fastest to start up?
A pip install, marginally — the binary unpacks itself on each run, which costs a fraction of a second. Irrelevant for a single download; noticeable if you are invoking yt-dlp thousands of times in a loop.

Related