Bluesky Video Downloader

How this Bluesky video downloader gets the file

Bluesky runs on the AT Protocol, and that changes what it takes to download Bluesky videos.

Every post is a record in the poster's repository, held on their PDS, or Personal Data Server. The record's real address is a URI like at://did:plc:z72i7hdynmk6r22z27h6tvur/app.bsky.feed.post/3k2yx4rmgnc2b: the account's DID, a permanent identifier that survives a username change, then the record type, then the record key.

That is never the link you paste. You copy bsky.app/profile/alice.bsky.social/post/3k2yx4rmgnc2b, which uses the handle instead. Handles are rented and move between accounts, so the first job is resolving one to the DID that owns it, through a DNS record or a file served at the handle's domain. Then you have the post's permanent address.

Attached to that record is the video, stored as a blob. A blob is content-addressed: referenced by a CID, a hash of the bytes, rather than by a filename. The record holds the CID, the aspect ratio, the alt text and any caption files. The bytes live on the PDS.

Playback takes a different path. On upload, the video service transcodes the file and publishes it to a CDN as HLS, which means the video is not one file. It's an .m3u8 playlist pointing at a ladder of quality variants, each variant its own playlist pointing at a run of .ts segments a few seconds long. Your player pulls the chunks as it goes, which is why a post plays instantly and quietly changes quality on a bad connection.

It's also why right-click and Save video as gives you nothing useful. There's no single file behind the player. Getting an MP4 means fetching every segment in order, joining them, and rewriting the result into an MP4 container. That last step is a remux rather than a re-encode: the bytes are copied across untouched and only the packaging changes.

Three consequences follow, and they're the ones people get wrong. Quality is fixed at whatever the transcode produced: those ladders typically top out around 720p, and nothing recovers detail already thrown away. There is no 4K option, whatever a tool claims — Bluesky never made a 4K rendition, so nothing can hand you one. And a very fresh post can fail: transcoding runs after the upload, and until it finishes there's no playlist to read. Try fifteen seconds after posting and you'll get a failure that isn't a bug.

Federation, and why the video isn't always where you'd expect

Here's the part no other page on this subject covers. The network is open, and the app you use isn't the only place the data lives.

Anyone can run their own PDS, and plenty of people do, on a small server with their own domain as their handle. Their posts show up in the app like everyone else's, because the app view is a separate service that crawls the network and assembles the timeline you read. It's a convenience layer, not the source of truth.

So a downloader can't assume one hostname. It resolves the DID to an identity document, reads the service endpoint listed there, and goes wherever the video actually lives. For an account on Bluesky's own infrastructure that endpoint is one of theirs. For a self-hosted account it's a machine in somebody's flat. A tool that hardcodes a single domain silently fails on the second kind.

This matters more over time, not less. Every account that moves to its own server becomes a link that breaks on tools which never learned to resolve identity properly.

GIFs on Bluesky are not videos

A Bluesky GIF is usually not uploaded media at all. The GIF button in the composer searches Tenor, and picking one attaches an external link embed: a URL, a title and a thumbnail pointing at a file on Tenor's servers.

That's a different object with different rules. It isn't a blob in the poster's repository, it has no CID, and it never touched the video service or the HLS pipeline. The file behind it is usually an MP4 Tenor serves, which is why these are silent and loop.

Practically, they save quickly at whatever size Tenor hosts, with no quality ladder to choose from. If someone uploaded an actual GIF file as media instead, it behaves like any other blob.

Quotes, reposts, and deleted posts

Reposts carry no media. A repost is a small record pointing at someone else's post, so either link lands in the same place.

Quote posts embed another record, and the quoting post can carry its own video on top of the one it's quoting. If the video you want is on the quoted post, open that post and copy its own link — the most reliable way to say which of the two you mean.

Deleted posts are gone. Deleting the record removes the reference to the blob, and an unreferenced blob gets cleaned up on the server that held it. We archive nothing and won't pretend otherwise.

Custom feeds change none of this. A feed generator returns a list of post addresses and the app fetches the posts, so a video from a niche feed is stored like any other. Open the post and copy its link. A feed URL holds no media.

Backing up your own posts, and what to do with them next

The strongest reason to use this on your own account is a migration. The AT Protocol lets you move to a different server and keep your identity, and blobs are handled separately from records in that process. Pulling down the videos you care about first takes a few minutes.

Then the obvious next step, which here is unusually direct: Unsora has a Bluesky scheduler. Save a clip, run it through AI clipping to cut it to a captioned vertical, and schedule it straight back out to Bluesky, or to TikTok, Instagram, YouTube, Facebook and LinkedIn alongside it. Save it, cut it, schedule it. All of it is callable over one MCP connection from the AI tools you already use.

Plans start at $19/mo with a 3-day free trial. This downloader is free and stays free. It isn't a trial.

Next steps

Post links out to YouTube? save it from YouTube.

Reposting on your own account? schedule the Bluesky post and let it go out on time.

Want more from your assistant? browse the skills library.