Fix "PO Token required" and Missing Formats in yt-dlp

Why a missing token looks like nothing being wrong

When yt-dlp asks YouTube what formats a video has, it identifies as one of several clients. The web client's answer now depends on whether the request carries a PO token — a value produced by YouTube's own obfuscated JavaScript running in a real browser, attesting that the request came from somewhere plausible.

Without one, YouTube does not refuse. It answers with a format list where the high-quality entries have no usable URL attached. yt-dlp skips those, prints the warning above, and downloads the best of what is left — which is the single combined 360p stream that has been there since 2010.

So the visible symptom is not an error at all. It is a file that is smaller and blurrier than expected, from a command that reported success. Plenty of people never connect the two, which is why "yt-dlp only downloads 360p" is a more commonly searched phrase than the actual warning text.

Recognising it

Ask for the format list. If the table stops at 360p on a video you know is available in 1080p, the formats are being withheld rather than missing:

Other phrasings of the same underlying problem, all worth treating identically:

• Some web client https formats have been skipped
• YouTube is forcing SABR streaming for this client
• PO Token is required / Missing a url
• nsig extraction failed alongside a truncated format list

The fixes, in the order worth trying

1. Use a client that does not need one

The television client authenticates differently and is not subject to the same check. It is the fix for the large majority of cases, it needs no account, and it costs nothing:

Worth putting in your config file rather than retyping — although with the caveat that the working client list changes, so it is also the first line to remove when something later stops working.

2. Update, and consider the nightly channel

This is an active arms race. Fixes land in nightly builds days before they reach a numbered release, and for this particular problem that gap matters:

Which install method you used decides whether these commands work at all — a distribution package cannot self-update and is often months behind.

3. Let a plugin generate tokens

If you need the web client specifically — some videos are only available through it — the provider plugin runs a minimal JavaScript runtime locally and produces real tokens:

Installation instructions live with the yt-dlp PO token guide, which is kept current in a way an article cannot be. It is more moving parts than most people need; try the TV client first.

4. Supply a token by hand

Extractable from a browser's network tab, and viable for a one-off. Tokens are bound to a session and expire, so this does not scale to a script:

Confirming it worked

Compare the format table before and after. Success looks like 1080p and above reappearing:

If the resolutions came back but the download is still 360p, the problem has moved: either your format selector is asking for the wrong thing, or ffmpeg is missing and yt-dlp cannot merge the separate streams it now has access to. Both are covered on the 360p page.

Why this is getting more common, not less

SABR — YouTube's newer adaptive streaming protocol — is being rolled out client by client, and it makes the proof-of-origin check structural rather than an add-on. Expect the set of clients that work without a token to keep shrinking.

The practical consequence is that any guide claiming a permanent solution to this is wrong, including this one in six months. Two habits survive: keep yt-dlp genuinely current, and check -F rather than trusting that a successful download got you the quality you asked for.