yt-dlp Cookies: --cookies-from-browser vs cookies.txt

What cookies do and do not do

A cookie carries a session identifier. Sending it makes the request look like it came from your signed-in browser, which is exactly what you want for content gated on an account.

What it does not do is prove the request came from a browser at all. YouTube now checks that separately, with a proof-of-origin token that yt-dlp cannot produce. That is why supplying cookies often does nothing for "Sign in to confirm you're not a bot" — the error asks for cookies, and cookies are not what is missing.

Method 1 — read the browser directly

Nothing to export, nothing to keep current:

Supported: firefox, chrome, chromium, edge, brave, opera, vivaldi, safari, whale.

In practice this splits cleanly in two. Firefox works while it is open. Chromium browsers do not:

• They hold an exclusive lock on the cookie database while running, so Chrome has to be fully closed — including background processes — or the copy fails.
• Since Chrome 127 the cookies are encrypted with a key bound to the browser process, so even a perfect copy decrypts to nothing.
• On Linux, the key lives in the desktop keyring, which does not exist over SSH — permission denied.

Method 2 — export a cookies.txt

Works from any browser including recent Chrome, and it is the only option for anything scheduled or headless. Install an extension that exports Netscape format, export while on the site, then:

Netscape format, which is what yt-dlp reads, looks like this. If your export is JSON, it is the wrong format:

Choosing between them

Interactive use on a desktop: read the browser, and use Firefox. Anything automated: export a file, lock its permissions, and expect to replace it.

Verifying

Verbose output states how many cookies were extracted. Zero means the wrong profile or browser. Several hundred with access still refused means the session is valid and the account lacks permission — see private video.

Keeping the file safe

A cookies.txt is a live session in plain text. Anyone who reads it is signed in as you, without a password and without a second factor.

• chmod 600, so other accounts on the machine cannot read it.
• Not in a git repository. Add it to .gitignore before you create it, not after.
• Not in Dropbox, OneDrive or iCloud.
• Mounted read-only into containers.
• Deleted when the job is done, and re-exported next time.

Combining with a client override

On YouTube you often need both — the account for access, and a client that is not separately challenged:

Avoid pairing cookies with player_client=tv: it authenticates differently and the mismatch can invalidate the session, logging you out of the browser you exported from.