Skip to content

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

↑ ↓ to move, ↵ to open esc to close

Fix "nsig extraction failed" and 50 KiB/s Downloads in yt-dlp

Tested on yt-dlp 2026.07.28 Updated
What yt-dlp prints 
WARNING: [youtube] dQw4w9WgXcQ: nsig extraction failed: Some formats may be missing
         Install PhantomJS to workaround the issue. Please download it from https://phantomjs.org/download.html
         n = xk3PqR9vLm2wQzT ; player = https://www.youtube.com/s/player/a1b2c3d4/player_ias.vflset/en_US/base.js

Quick answer

This warning is why a download crawls at 50 KiB/s instead of failing outright. yt-dlp could not solve YouTube's throttling parameter, so the request goes out unsigned and YouTube serves it slowly on purpose. An update fixes it more often than any flag:

the fix, most of the time 
yt-dlp -U && yt-dlp --rm-cache-dir

What the n parameter does

Every YouTube media URL carries a parameter called n. Before the URL can be used at full speed, that value has to be transformed by a JavaScript function inside YouTube's player, and the result sent back. Get it right and you download at line speed. Get it wrong, or omit it, and YouTube serves the file at a deliberately throttled rate.

So this is not a signature check in the security sense. It is a speed control, and that explains the symptom precisely: nothing fails, nothing is blocked, and a 200 MB video takes an hour.

yt-dlp handles it by downloading the player script, locating the function, and re-implementing it in Python. YouTube changes that function regularly — sometimes to fix bugs, sometimes specifically to break tools that read it. When the new shape defeats yt-dlp's parser, you get this warning.

The fixes, in the order worth trying

1. Update

A player change is usually handled within a day or two of appearing. If your build predates the fix, nothing local will help:

bash 
yt-dlp --version
yt-dlp -U

2. Clear the cached player

yt-dlp caches its analysis of the player. If the cache holds a parse of an older player while YouTube is serving a newer one, the mismatch produces exactly this:

bash 
yt-dlp --rm-cache-dir

3. Install a JavaScript runtime

When the function is too convoluted to re-implement, yt-dlp can execute it instead — if there is something on the machine able to run JavaScript. Deno is the lightest option:

macOS and Linux 
curl -fsSL https://deno.land/install.sh | sh
Windows 
winget install DenoLand.Deno

Node.js works equally well and is probably already installed if you do any web development. yt-dlp finds either automatically — there is no flag to set.

4. Switch to the nightly channel

Player changes are exactly the class of problem the nightly builds exist for. The fix typically lands there days before it reaches a numbered release:

bash 
yt-dlp --update-to nightly

5. Use a client that skips the check

The television client is not subject to the same throttling parameter:

bash 
yt-dlp --extractor-args "youtube:player_client=tv" "URL"

Occasionally faster than waiting for a parser fix, and the same flag helps with the PO token problem, which frequently appears alongside this one.

Confirming it worked

Two things to look for. First, that the warning is gone. Second — and this is the one that matters — that the speed is back:

bash 
yt-dlp -f "bv*[height<=720]+ba/b" --newline "URL"

Anything in MiB/s is healthy. Anything in double-digit KiB/s means the throttle is still on, even if nothing was printed about it.

If it still fails

  • Warning gone, speed still awful. Then it was never the n parameter. Try --concurrent-fragments 4, and check whether your ISP throttles video CDN traffic — testing at a different time of day usually settles that question.
  • Warning persists on a fresh nightly with Deno installed. YouTube has shipped something new and the fix is not written yet. Check the issue tracker — when this breaks it breaks for everyone at once, and there will already be a thread.
  • Only some videos. YouTube A/B tests players. Retrying an hour later often hits a different one.
  • Formats missing entirely rather than slow. Different problem wearing similar words — see PO tokens and stuck at 360p.

Frequently asked

Why is the download slow rather than failing?
Because YouTube does not reject an unsigned request — it serves it at a fraction of normal speed. The n parameter is a throttling control, so a wrong answer means slow, not blocked. That is why the symptom is 50 KiB/s rather than an error.
Does a faster connection help?
No. The cap is applied at YouTube's end. A gigabit line downloads at the same 50 KiB/s as a DSL one when the n parameter is unsolved.
Why does yt-dlp need a JavaScript interpreter for this?
The transformation is defined by a function inside YouTube's player script, and it changes without notice. yt-dlp reads that function and re-implements it. When the code changes shape enough that its parser cannot follow, extraction fails until someone updates the parser.
Is installing Deno or Node safe?
Both are mainstream runtimes from their own vendors, and yt-dlp uses them only to evaluate the player function. The risk is comparable to having any other developer tool installed. If you would rather not, updating yt-dlp resolves this most of the time anyway.

Related