yt-dlp · Subtitles · Troubleshooting
yt-dlp: Sign in to confirm you're not a bot
YouTube's player asked for a signed-in session. Update yt-dlp first. Cookies are the hint in the error, and they tie the job to a Google account. The same message appears when you only asked for subtitles.
· 3 min read · YTAPI
yt-dlp stops with:
ERROR: [youtube] dQw4w9WgXcQ: Sign in to confirm you're not a bot.yt-dlp then tells you to pass --cookies-from-browser or --cookies, and links to its FAQ. That hint moves between releases. The sentence above is YouTube's. The player refused an anonymous client and asked for a signed-in session. --skip-download --write-subs hits it too. YouTube applies the check to the client, whether or not you save the video file.
This page is about getting the subtitle file past that check. It is not a video downloader.
Update before you touch cookies
YouTube changes the player often. An old yt-dlp build fails the same request a current build completes, and the error string looks identical. Packages installed with apt or Homebrew sit weeks behind. Check what you are running:
yt-dlp --version
yt-dlp -U-U updates the official binary. A pip install updates with pip install -U yt-dlp. If the new build prints that a JavaScript runtime is missing, install the one it names. YouTube's player script has to be executed to get past parts of this check, and the runtime yt-dlp wants has changed before. Trust the message from the build you just installed.
Try one video again before changing anything else. A lot of reports end here.
Cookies, if it is your machine
The error tells you to pass cookies. The yt-dlp FAQ documents --cookies-from-browser and a cookies.txt file for sites that require a login or a CAPTCHA.
yt-dlp --cookies-from-browser firefox \
--skip-download --write-subs --write-auto-subs --sub-langs "en.*" \
"https://www.youtube.com/watch?v=dQw4w9WgXcQ"That sends your YouTube session with the request. It works for a script you run yourself, on a machine where you are already signed in. It is a poor fit for a server:
- The session expires, and the error comes back.
- Logging out, or changing the account password, kills the file you exported.
- The traffic is attached to a Google account. Accounts used this way get restricted.
- Putting a user's cookies on a server you operate is their Google account, in your process.
--cookies-from-browser reads the browser profile on that machine. It does nothing on a container that has no Firefox profile. A copied cookies.txt goes stale.
A datacenter IP
The same sentence shows up on AWS, GCP, Vercel, and anywhere else whose addresses YouTube already treats as automated. Cookies sometimes get a single server through. They do not turn a hosting range into a home connection, and the account risk stays. Slowing the requests down is the remedy for HTTP 429, which is a different response. A bot check on every video, including the first one of the day, is the address.
From a server, the durable options are a residential proxy in front of yt-dlp, or not using yt-dlp for this request. --proxy takes an HTTP or SOCKS URL. The exit address has to be a consumer address. A datacenter proxy is refused for the same reason the server was.
When you only needed the words
If the video file was never the point, a transcript API replaces the subtitle flags with one request. Your server talks to the API. It does not get a video, an audio file, or a session cookie.
curl -s https://api.ytapi.dev/v1/transcripts \
-H "Authorization: Bearer $YTAPI_KEY" \
-H "Content-Type: application/json" \
-d '{"video_id": "dQw4w9WgXcQ", "format": "vtt"}'format can be vtt, srt, text, or segments. A video with no captions returns 404 and is not billed. Details and the language list are in the extract reference. The Python equivalent, including what TranscriptsDisabled means in the other common library, is in the Python guide.
FAQ
Is it safe to use cookies from my main Google account?
It's a risk. Automated requests signed in with your account can get that account flagged. If you use cookies, use a separate account you can afford to lose.
Why does it only happen on my server?
Servers use datacenter IP addresses, which YouTube challenges far more often than home connections. The same applies to youtube-transcript-api; see why cloud servers get blocked.
I only need subtitles. Do I need yt-dlp at all?
No. If you just want the caption text, a transcript API returns it without downloading anything else, as in the example above. If you also need the video or audio, you still need a downloader.