A cookie jar for yt-dlp

A simple idea for keeping yt-dlp working, by rotating cookies from different sessions

Something that most people who deploy a project dependent on yt-dlp will know is that it can stop working at any moment. YouTube continuously maintains strategies to prevent unauthenticated access to content. One “consistent” way to circumvent this is to spoof yourself as a real session, and one of the main ways to do that is to pass cookies into yt-dlp.

However, this is no siver bullet. Browser cookies are ephemeral and therfore expire after some time. For those unaware, your browser automatically requests new cookies from YouTube every so often, which allows you to stay continuously logged in even the next day (and if they detect something is off, they’ll force you to re-authenticate). This is great, but a static cookies.txt file can’t exactly “refresh” itself.

Solution

One solution I’ve come up with is what I’ve come to call a cookie jar. yt-dlp comes configured with the ability to read the cookies from your browser.

yt-dlp --cookies-from-browser firefox --cookies cookies.txt

Since YouTube is a commonly used application, one idea is to take advantage of this and send your cookies to the server using yt-dlp on a set interval.

To scale it up, if you have multiple machines that commonly make use of YouTube, you can also use those to build up a sort of “cookie jar” for the server to pull from. In theory, whenever users use YouTube these cookies will refresh, meaning that the chances of not having a valid cookie available are quite low.

Now how you do this is entirely up to you, but I would probably stick to using this only on local networks due to the sensitivity of exposing your cookies. You can also make use of something like scp via a bash script for this.

Why not have each host run a webserver and make requests for it to generate cookies?

The key point of this is that it’ll work pretty much with minimal impacts to any system usage, running a webserver is not that, and in my mind it increases the risk of potential cookie leakage.