yt-dlp: "Sign in to confirm you're not a bot" — Why It Happens and How to Fix It

yt-dlp failing with 'Sign in to confirm you're not a bot'? Here's why YouTube blocks it and every fix that works — updating yt-dlp, browser cookies, PO tokens, rate limiting, and clean IPs.

Dalvo · Updated July 17, 2026

If yt-dlp suddenly stops working with this:

ERROR: [youtube] VIDEO_ID: Sign in to confirm you're not a bot.
Use --cookies-from-browser or --cookies for the authentication.

…YouTube has flagged your request as automated and is refusing to serve the video without a signed-in session. This started appearing far more often in 2024–2025 as YouTube ramped up bot detection, and it's now one of the most common yt-dlp failures.

Here's what triggers it and every fix that actually works, in the order most likely to resolve it.

Why YouTube shows "confirm you're not a bot"

YouTube decides a request looks robotic and demands proof of a real, signed-in user. The usual triggers:

Your yt-dlp is out of date — YouTube changed something and your version's extractor hasn't caught up.
You're on a flagged IP — datacenter IPs (AWS, GCP, Azure, most VPS/CI) are heavily scrutinized, so a script that works on your laptop fails on a server.
No authentication — anonymous requests get challenged more aggressively, especially at volume.
Too many requests — rapid, repeated calls from one IP trip rate-based bot detection.

Closely related to 403 Forbidden

This message rejects the metadata request; a 403 Forbidden rejects the media request. Same root cause, and the fixes below overlap heavily.

Fix 1: Update yt-dlp first

Most "not a bot" errors are just a stale binary. YouTube breaks extractors constantly and the maintainers patch them quickly — but only new releases get the fix.

yt-dlp -U

apt/brew builds are stale

Distro packages of yt-dlp are often weeks behind — old enough to trigger this error on their own. Use yt-dlp -U or pip, then check yt-dlp --version.

Fix 2: Pass your browser cookies

This is the fix YouTube's own error message suggests. Exporting cookies makes yt-dlp request as a logged-in user.

Sign in to YouTube in a browser
Log into your Google account in Chrome, Firefox, Edge, Brave, or Safari as you normally would.

Point yt-dlp at that browser's cookies

yt-dlp --cookies-from-browser chrome "https://www.youtube.com/watch?v=VIDEO_ID"

On headless servers there's no browser to read, so export a cookies.txt on a normal machine and copy it over (the last tab above).

Cookies are fragile to automate

Session cookies expire, and YouTube invalidates them faster when it sees them used from a datacenter IP. Great for a one-off download; painful to keep alive in production.

Fix 3: Force a different player client

YouTube serves different challenges to different clients. Forcing the android or ios client sometimes sidesteps the check entirely:

yt-dlp --extractor-args "youtube:player_client=android" "https://www.youtube.com/watch?v=VIDEO_ID"

Which clients work shifts over time as YouTube adjusts trust — treat this as a moving workaround. Newer yt-dlp versions also support PO tokens for tougher cases; check yt-dlp's docs if the clients above stop helping.

Fix 4: Slow down

Bulk downloads are the fastest way to get flagged. Add pauses and rate limits:

yt-dlp --sleep-requests 2 --sleep-interval 5 --max-sleep-interval 15 --limit-rate 2M \
  "https://www.youtube.com/watch?v=VIDEO_ID"

Fix 5: Get off flagged IPs

If it only happens on a server, your IP reputation is the problem. Route through residential proxies, rotate IPs, or move the workload somewhere with cleaner reputation:

yt-dlp --proxy "http://user:pass@residential-proxy:port" "https://www.youtube.com/watch?v=VIDEO_ID"

Want to know if the video is even the problem?

Paste the URL — if our API returns a file, the video is fine and the block is on your setup.

Paste a link. See it work.

Paste a YouTube link, pick a format, and hit download.

When the fixes stop scaling

Each fix works for one download on one machine. In production, none of them stay fixed: yt-dlp needs re-updating every couple of weeks, cookies expire, player-client tricks change, and IPs get flagged. Teams that download YouTube programmatically end up maintaining a cookie-rotation-and-proxy side project instead of shipping their own product.

Never see this error again.

Dalvo, our YouTube download API, handles bot detection, cookies, player clients, and IP reputation on our side. Send a URL, get a direct download from our CDN — no sign-in prompts, no maintenance.

Start free

Quick reference

Situation	First thing to try
Happens on every video	Update yt-dlp (`yt-dlp -U`)
Only age/members-only videos	`--cookies-from-browser`
Only on a server / cloud host	Flagged IP — residential proxy
During bulk downloads	`--sleep-interval` + `--limit-rate`
Still stuck after updating	Force `player_client=android`, or PO tokens

Frequently asked questions

Why does yt-dlp work on my laptop but not on my server?+

Datacenter IPs (AWS, GCP, Azure, most VPS providers) are heavily bot-flagged, so YouTube challenges them far more often than a home connection. The same command can succeed locally and fail on a server purely because of IP reputation.

Is it safe to use my main Google account's cookies?+

Using cookies ties the downloads to that account, and heavy automated use from a flagged IP can get the account rate-limited or challenged. For anything beyond occasional use, prefer a throwaway account or a managed API.

Do I have to keep updating yt-dlp forever?+

With self-hosted yt-dlp, effectively yes — YouTube's changes guarantee recurring breakage, so you re-update, re-export cookies, and adjust flags on an ongoing basis. A managed API absorbs that maintenance instead.