Skip to content
SnapFrom

Why YouTube Downloaders Broke: SABR and Proof of Origin

· · 7 min read

If a YouTube downloader stopped working for you sometime in the last year and a half, there is a good chance you saw a line like this go past:

YouTube is forcing SABR streaming for this client. Some web client https formats have been skipped as they are missing a url.

That message is not a bug in the tool. It is the tool correctly reporting that YouTube has stopped giving it what it used to ask for[2].

This is what changed, and what the ways around it actually cost.

What used to happen

For most of YouTube’s life, asking for a video’s metadata got you a list of formats with a URL attached to each one. Pick a resolution, fetch the URL, get the bytes. Every downloader ever written is built on that shape, and so is a good deal of legitimate software.

In February 2025 that stopped being true for YouTube’s web client. The playback links were removed from the adaptiveFormats list in the player response, leaving a single SABR URL in their place[1]. There was nothing to fetch any more, only a protocol to speak.

What SABR is

SABR is YouTube’s own streaming protocol. Google has not published a specification for it, and the practical evidence of that is that other people have had to build one: the googlevideo project exists specifically as “a collection of modules for working with YouTube’s proprietary video streaming protocols (UMP/SABR)”[4].

That word - proprietary - is the whole story. A tool that wants a video can no longer make a request. It has to hold a conversation, in a language nobody outside Google has documentation for, that can change whenever Google feels like changing it.

This is a meaningfully different situation from the fingerprinting arms race that broke downloaders in earlier years. That was a fight about looking like a browser. This is a fight about speaking a protocol, and losing it does not produce a slow download or an occasional failure. It produces no file at all.

The second lock: proof of origin

Speaking the protocol is not sufficient on its own. Some clients are also required to present a PO Token - short for Proof of Origin - which yt-dlp’s own guide describes as a parameter YouTube requires “to attest that requests are coming from a genuine client”[3].

The consequence of not having one is stated plainly in the same guide. Requests for the affected clients’ format URLs “may return HTTP Error 403, or result in your account or IP address being blocked”[3].

Read that second clause again, because it is the part that matters and the part no downloader’s front page mentions. The failure mode is not only that the download fails. It is that the attempt itself can cost you the account or the address you made it from.

Why logging in does not fix it

The intuitive move, when a site starts demanding proof you are real, is to hand it a real session. It does not work here.

One reported case supplied a full cookies file and still got the SABR warning and 403s on the fragments it tried to fetch[2]. Cookies prove who you are. SABR and PO Tokens are asking what you are, and a script with your cookies in it is still a script.

There is a nastier edge to this. Per the guide above, the penalty for failing that check can land on the account[3]. So the workaround that feels safest - log in properly, behave like a normal user - is the one that puts something you care about on the table. An anonymous request that gets an IP blocked costs you a coffee shop. A logged-in one that gets an account blocked costs you your subscriptions, your history and your channel.

What the real workaround costs

There is a supported answer, and it is worth being precise about what it involves. yt-dlp’s guide points users at a PO Token Provider plugin, and one of the recommended ones generates tokens by driving YouTube in an actual browser[3].

That is the tell. The reliable way to prove you are a real browser is to be a real browser. Which means the lightweight command-line tool now has a browser attached to it, and the cost profile changes completely:

  • Weight. You are running a browser per download rather than an HTTP request.
  • Fragility. The token provider is a separate moving part, maintained separately, that can break on its own schedule.
  • It does not scale. This is survivable on your own machine for one video. A web service doing it for thousands of strangers is running thousands of browsers, which is expensive enough to change what the service has to charge or harvest from you.

Alongside this, the older costs have not gone away. yt-dlp still ships --impersonate to reproduce a specific browser’s TLS and HTTP fingerprint, and its README notes that doing so can have “a detrimental impact on download speed and stability”[5].

Why some things still work

Not every client is affected the same way. The web client took the hit first, and tools have kept working by falling back to clients that still hand out ordinary URLs, or to lower-quality formats that were never moved[2].

This is worth understanding correctly, because it is the source of most confusion about whether downloaders “work”. They often half-work: you get a file, but it is a lower resolution than you asked for, or audio and video come from different places, or it succeeds today and fails next week. That is a fallback chain doing its job, not a tool operating normally.

It is also inherently temporary. Every one of those fallbacks is a client Google has not closed yet.

What each route costs now

RouteGets a real fileWhat it actually costs
YouTube app offlineNo - encrypted, expires, stays in the appA subscription, and it is not a file you own
Creator-provided downloadYesRarely offered
Command-line tool, anonymousSometimes, often at reduced qualityBreaks without warning; IP can be blocked
Command-line tool with a token providerMore oftenA browser per download; another component to maintain
Command-line tool, logged inNot reliably betterPuts the account itself at risk
Web downloader serviceSometimesEverything above, borne by someone whose incentives are not yours

What this actually means

The honest summary is that the ground has shifted from “can this tool imitate a browser well enough” to “can this tool reimplement an undocumented protocol, and keep reimplementing it”. The first is a maintenance burden. The second is an open-ended commitment against a party that can change the rules unilaterally and has every reason to.

If you want a specific video to still exist for you in five years, the durable answers remain what they always were: ask the creator, check whether they publish it somewhere themselves, or use the platform’s own offline feature and accept its limits. Every other route is a bet on somebody else continuing to win a fight on your behalf.

And if you are going to use a tool anyway, the two things worth knowing are the ones this page opened with: it will break without telling you why, and the account you are logged into when it breaks is not free of consequence[3].

Frequently asked questions

Is SABR the reason my downloader gives a 403?

Often, but not always. A 403 on a format URL is the documented symptom of a missing PO Token[3], which is related to but separate from SABR itself. The clearest signal that you are looking at SABR specifically is the “forcing SABR streaming” warning naming a client whose formats were skipped for having no URL[2].

Will updating the tool fix it?

Sometimes, and that is the pattern rather than the exception. Fixes here take the shape of finding another client that still works, so an update buys you the gap until that one closes too. It is not the same as a bug being fixed.

Does a paid YouTube plan remove the restriction?

Not in the sense people usually mean. yt-dlp’s guide notes that Premium subscribers are not required to supply a GVS PO Token[3], which is a narrower statement than paying making third-party downloading supported. The offline feature inside the app remains the route YouTube actually authorises, and it does not give you a file you can keep.

Is any of this illegal?

That is a separate question from whether it works, and it depends on where you are and what you do with the file afterwards. Working around a technical access control is treated very differently from copying something in most legal systems. We have written about what YouTube’s terms permit in Downloading YouTube Videos: What’s Allowed, What Breaks.

Sources

  1. [youtube] `web` only has SABR formats (issue #12482) - yt-dlp project, accessed

    Supports: YouTube removed the playback links for adaptiveFormats in the web client player response, leaving only SABR streaming URLs; the issue was opened on 26 February 2025 and remained open with an associated pull request.

  2. YouTube is forcing SABR streaming for this client despite using --cookies cookies.txt (issue #13968) - yt-dlp project, accessed

    Supports: The literal warning users see reads 'YouTube is forcing SABR streaming for this client. Some web client https formats have been skipped as they are missing a url', and supplying a cookies file did not prevent SABR being enforced.

  3. PO Token Guide - yt-dlp project, accessed

    Supports: A PO Token is a parameter YouTube requires from some clients to attest that requests come from a genuine client; without one, requests for the affected clients' format URLs may return HTTP Error 403 or result in the account or IP address being blocked; obtaining one in practice means running a PO Token Provider plugin, one of which generates tokens by driving YouTube in a real browser.

  4. googlevideo - LuanRT, accessed

    Supports: The project describes itself as a collection of modules for working with YouTube's proprietary video streaming protocols (UMP/SABR), which is evidence that the protocol is proprietary and had to be reimplemented by third parties rather than being an open standard.

  5. yt-dlp README - yt-dlp project, accessed

    Supports: yt-dlp ships --impersonate, built on curl_cffi, to reproduce a specific browser's TLS and HTTP fingerprint, and --cookies-from-browser to reuse a logged-in session, and notes that impersonating requests can have a detrimental impact on download speed and stability.