yt-dlp cookies: how to export them, use them, and why they stop working

By Tunelio team·Published Sep 7, 2026

Cookies let yt-dlp present a real YouTube session, which clears “Sign in to confirm you’re not a bot” and unlocks age-restricted or members-only videos. Done wrong, they get your Google account restricted and still stop working after a day. This guide shows the safe way: a spare account in a private window, one export, and the flags that go with it.

The short version

# 1. private window → log in to a SPARE Google account → open https://www.youtube.com/robots.txt
# 2. export cookies.txt with a "Get cookies.txt LOCALLY"-style extension → close the window
yt-dlp --cookies cookies.txt -4 "https://youtu.be/dQw4w9WgXcQ"

That is the whole recipe the yt-dlp maintainers recommend: a session nobody else touches, exported from a page that does not rotate the token, then never opened in a browser again. Everything below explains why each part matters and what to do when cookies still fail.

When you actually need cookies

• YouTube answers with “Sign in to confirm you’re not a bot” and updating yt-dlp, installing a JS runtime and forcing IPv4 did not clear it.
• The video is age-restricted, members-only, private (shared with your account) or in a private playlist.
• You want your own account’s subtitles, history or region behaviour to apply.

For plain public videos on a home connection you do not need cookies at all. Adding them “just in case” is how people end up with a locked account and a jar that expires weekly.

Two ways to pass cookies

--cookies FILE (recommended for servers)

Takes a Netscape-format cookies.txt. This is the method to use on a VPS, in Docker and in scripts: the file is explicit, portable and does not depend on a browser being installed. Export it once from a private window (steps below) and keep it out of version control.

--cookies-from-browser BROWSER (convenient on your own machine)

yt-dlp --cookies-from-browser chrome "https://youtu.be/dQw4w9WgXcQ"
# firefox, chromium, edge, brave, opera, safari, vivaldi are supported;
# pick a profile / container with  firefox:profile_name  or  chrome:Default

yt-dlp reads the browser’s cookie database directly. It works well for one-off local use, but it reads your everyday account, the browser keeps rotating the session while it is open, and on Linux it may need keyring access. Do not use it for automation.

Exporting cookies the right way (step by step)

• Open a private/incognito window so no other YouTube tab shares the session.
• Log in to a spare Google account created for this purpose — not the account you care about.
• Navigate to https://www.youtube.com/robots.txt. This page loads the session cookies but does not run the scripts that rotate them.
• Export with a cookies.txt extension that saves in Netscape format (the one recommended in the yt-dlp wiki is “Get cookies.txt LOCALLY”).
• Close the private window without visiting YouTube again. Every later YouTube page view in that session can invalidate the exported token.
• Move the file to the machine that runs yt-dlp, chmod 600, and pass it with --cookies.

Why cookies stop working

• Rotation: YouTube refreshes session tokens in the background while a browser tab is open. If you exported from a window you kept using, the file is already stale.
• Expiry: session cookies are short-lived by design; expect days to a few weeks, then re-export.
• IP reputation: a cookie jar cannot rescue a data-center IP that YouTube has already flagged. If cookies work for a day and then fail, the address is the problem — see the proxy guide.
• Wrong client: some player clients yt-dlp uses ignore cookies or must not receive them; yt-dlp warns when cookies are passed to a client that cannot use them.
• Format loss: the maintainers note that some formats become unavailable when cookies are passed — a media 403 that appears right after adding cookies is a known pattern.

Account safety

Automated traffic from a flagged server IP against a signed-in session is exactly what Google’s abuse systems look for. Accounts used this way get rate-limited, forced through verification or locked. Keep one rule: the cookies you give yt-dlp on a server belong to an account you can afford to lose. Never share a cookies.txt in a chat or ticket — it is a full login.

Cookies in scripts, cron and Docker

# keep the jar outside the image and mount it read-only
docker run --rm -v "$PWD/cookies.txt:/cookies.txt:ro" -v "$PWD/out:/out" \
  yt-dlp-image yt-dlp --cookies /cookies.txt -4 -o "/out/%(title)s.%(ext)s" "URL"

yt-dlp rewrites the cookie file with refreshed values after a run when it can; mounting read-only prevents that, so re-export on a schedule instead. Log the yt-dlp version and the cookie file’s age with every failure — most “cookies broke” tickets are a stale jar plus an outdated binary.

When cookies are the wrong tool

If yt-dlp powers a bot, an app or a pipeline, cookie hygiene becomes a recurring chore: rotation every few weeks, spare accounts, IPs that need replacing anyway. A hosted API keeps sessions, PO tokens and residential exits on its side and returns a download URL in one request:

curl "https://tunelio.dev/create?url=https://youtu.be/dQw4w9WgXcQ&quality=720p" \
  -H "Authorization: Bearer tnl_your_api_key"

Tunelio is our own service; for occasional downloads from your laptop, --cookies-from-browser and the free tools are all you need. New accounts get 100 free credits, no card required.

Sources

• yt-dlp wiki — “How do I pass cookies to yt-dlp?” (private window, robots.txt trick, rotation).
• yt-dlp README — --cookies and --cookies-from-browser reference.
• yt-dlp issue tracker — reports of formats becoming unavailable with cookies (2026).