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 -Uapt/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 freeQuick 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.