Skip to content

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

↑ ↓ to move, ↵ to open esc to close

Install yt-dlp on Linux Without Your Distro's Stale Package

Tested on yt-dlp 2026.07.28 Updated

Quick answer

On a rolling-release distribution, the package manager is fine. On anything with frozen versions — Debian stable, Ubuntu LTS, RHEL — the packaged yt-dlp is old enough that YouTube downloads simply fail. Install a build that updates itself instead:

bash 
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
yt-dlp --version

Why the packaged version is the problem

Distributions freeze package versions for the lifetime of a release. For a C library that is exactly right. For yt-dlp it is fatal: the program's job is to track sites that change every few weeks, and a build frozen eighteen months ago is tracking a version of YouTube that no longer exists.

The symptoms are not obviously "this is out of date". They are nsig extraction failed, unable to extract player response, and downloads that quietly cap at 360p. Every one of them is people debugging a package manager's release policy.

DistributionPackaged yt-dlpRecommendation
Arch, ManjaroDays behindpacman -S yt-dlp
FedoraWeeks behinddnf install yt-dlp
openSUSE TumbleweedDays behindzypper install yt-dlp
Debian stableA year or moreBinary or pipx
Ubuntu LTSA year or moreBinary or pipx
RHEL, Rocky, AlmaNot packagedBinary

Ubuntu and Debian specifically have enough going on — pipx, the externally-managed-environment error, the PPA question — to deserve their own page.

The standalone binary

One self-contained file with Python bundled inside. Nothing to install first, and it updates itself:

system-wide 
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
one user, no root 
mkdir -p ~/.local/bin
curl -L https://github.com/yt-dlp/yt-dlp/releases/latest/download/yt-dlp -o ~/.local/bin/yt-dlp
chmod +x ~/.local/bin/yt-dlp

If the second form gives "command not found", ~/.local/bin is not on your PATH:

bash 
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

pipx

An isolated virtual environment per tool, without you having to manage one. The right answer if you would rather not have an unmanaged binary in /usr/local/bin:

bash 
sudo apt install pipx    # or dnf, pacman, zypper
pipx ensurepath
pipx install yt-dlp
pipx upgrade yt-dlp

ffmpeg

Install this from the package manager. Unlike yt-dlp it is not chasing a moving target, so a distribution build is fine:

bash 
sudo apt install ffmpeg        # Debian, Ubuntu
sudo dnf install ffmpeg        # Fedora
sudo pacman -S ffmpeg          # Arch
sudo zypper install ffmpeg     # openSUSE

On Fedora and RHEL, ffmpeg lives in RPM Fusion rather than the default repositories — enable it first. Without ffmpeg, yt-dlp cannot merge streams and every download caps at 360p.

Two installs at once

Installing the binary without removing the packaged one leaves two, and which runs depends on PATH order. That produces "I updated and it is still the old version", repeatedly:

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

If more than one path comes back, remove the packaged one — sudo apt remove yt-dlp or your distribution's equivalent.

Keeping it current

standalone binary 
yt-dlp -U
yt-dlp --update-to nightly

Nightly is worth considering on Linux specifically, because you are likely to be automating something. A cron job that fails silently for a week because an extractor broke is worse than the theoretical instability of a nightly build.

Cookies on a headless machine

--cookies-from-browser needs a desktop session: Chromium's cookies are encrypted with a key in the desktop keyring, and over SSH there is no keyring to ask. Export to a file once instead:

bash 
yt-dlp --cookies /home/user/cookies.txt "URL"
chmod 600 /home/user/cookies.txt

The permission-denied page covers keyrings, and the cookies guide covers exporting.

If it still fails

  • "externally-managed-environment" from pip. PEP 668 — the distribution is protecting its own Python. Use pipx or the binary; the Ubuntu page goes into it.
  • Works as your user, not under sudo. Different PATH. Use an absolute path in anything privileged.
  • Works interactively, not from cron. cron has almost no environment. Use absolute paths for yt-dlp and --ffmpeg-location, and redirect output somewhere you will read.
  • Snap or Flatpak browsers. Sandboxed profiles are not where yt-dlp looks; pass the path explicitly.

Frequently asked

Why is my distribution's yt-dlp so old?
Because distributions freeze package versions for the life of a release, which is the right policy for a library and the wrong one for a program whose job is to track a website that changes weekly. A yt-dlp from a stable repository is often a year behind and simply cannot download from YouTube.
Is Arch's package fine then?
Yes — rolling-release distributions ship yt-dlp within days. This whole page is really about the frozen ones: Debian stable, Ubuntu LTS, RHEL and their derivatives.
Where should the binary go?
/usr/local/bin is the standard location for software not managed by the package manager, and it is on PATH by default. ~/.local/bin is the equivalent for a single user and needs no root.
Can I keep both the packaged and the manual install?
You can, and it is a reliable way to confuse yourself — which one runs depends on PATH order. Remove the packaged one, or at least check with `which -a yt-dlp` before concluding an update did not work.

Related