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

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.

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

python3 -m pip install --upgrade --force-reinstall "yt-dlp[default]"

pipx upgrade yt-dlp

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.

1. Sign in to YouTube in a browser

   Log into your Google account in Chrome, Firefox, Edge, Brave, or Safari as you normally would.

2. Point yt-dlp at that browser's cookies

   ChromeFirefoxcookies.txt file

   Copy

   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).

Fix 3: Install a JavaScript runtime, and leave the player client alone

Current yt-dlp needs a JavaScript runtime (Deno by default) to solve YouTube's URL challenges. Without one, it falls back to fewer player clients, and the ones left are more likely to be challenged:

curl -fsSL https://deno.land/install.sh | sh
yt-dlp -v "https://www.youtube.com/watch?v=VIDEO_ID"

Older advice, including earlier versions of this page, says to force player_client=android. Don't do that with current yt-dlp. The Android client now needs a PO token for most formats and can't use cookies, so forcing it usually makes things worse. yt-dlp's default clients include ones that don't need a token. If the -v output warns that formats "require a GVS PO Token", install a PO Token provider plugin. yt-dlp not working covers that warning and the others like it.

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"

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.

Quick reference

Frequently asked questions