Fix "Sign in to confirm you're not a bot" in yt-dlp

What is actually being checked

YouTube runs several different playback clients — the web player, the Android app, the TV interface, and others. Each authenticates differently, and each is trusted to a different degree. yt-dlp can pretend to be any of them, and which one it picks decides whether you get a challenge.

Since 2024 the web client has required a proof-of-origin token: a value generated by YouTube's own JavaScript, in a real browser, that proves the request came from somewhere plausible. yt-dlp cannot manufacture one. When it identifies as the web client without one, the server sees a session that claims to be a browser and cannot prove it — and asks it to sign in to confirm it is not a bot.

This is why the advice in the error message has aged badly. Cookies tell YouTube who you are. They say nothing about where the request came from, and it is the second question failing.

The fixes, in the order worth trying

1. Update, then change client

Which clients work changes every few months, and yt-dlp's defaults change with them. A build more than a few weeks old is often trying a client that stopped working.

tv is the television interface — the least scrutinised client, and the one that works most often without any credentials. web_safari is the fallback if the first fails. Listing two separated by a comma means yt-dlp tries them in order.

2. Slow the request rate down

The check is not purely per-request. Six extractions in four seconds looks like a script no matter which client you claim to be, and a playlist does exactly that before downloading anything:

--max-sleep-interval is what adds jitter. A pause of exactly five seconds between every download is itself a machine signature; a random pause between five and fifteen is not.

3. Then cookies, from a throwaway account

If the video genuinely needs an account — members-only, age-restricted, private — no client switch will substitute for that. Cookies are the answer, with a caveat worth taking seriously.

Firefox is the example because Chrome and Edge lock their cookie database while running, which produces a different error entirely. Both methods, and when each one breaks, are in the cookies guide.

4. Combine client and cookies

For members-only content you may need both — the account to have access, and a client that is not challenged:

Confirming it worked

Test extraction without downloading anything:

A format table means the challenge cleared. An empty table, or one with only low-resolution entries, means extraction succeeded but the good formats are still gated — that is the PO token problem, not this one.

If it still fails

• Only on a VPN or a server. Datacentre IP ranges get the strictest treatment. There is no flag that fixes this; run it from a residential connection, or expect to need cookies plus a working client every time.
• Right after it worked fine. You tripped a rate limit. Wait an hour — most of these are temporary — and come back with the pacing flags above.
• Every video, every client, fresh install. Check for a --user-agent in a config file. A copied user-agent string that contradicts the client yt-dlp is claiming is a reliable way to fail this check; --ignore-config will tell you in one run.
• Nothing works and the video plays in a browser. The client list has moved again. The yt-dlp extractor wiki tracks which clients currently work; it changes faster than any article can.