bilidown: a desktop tool for taking Bilibili video apart and saving it locally

Four kinds of link, and one that is still pending

The scope is stated as a list of URL shapes, and that list is the clearest thing about the project. A single video is addressed by its BV identifier, a bangumi or TV episode by its season path, a video collection by its collection detail page, and a user's favourites folder by its favlist page. The fifth entry, a creator's space URL, is marked as waiting for version 3.x, which tells you the author intends the same four shapes to grow into a fuller crawler of the site.

What that list does not include is any notion of a subscription feed or a library. Nothing here browses; you paste a link and get files. That is a deliberate boundary and it is worth noticing, because several popular alternatives in this space are really front ends for a whole account. bilidown's own description lists the output formats it cares about: up to 8K video, Hi-Res audio, and Dolby Vision downloads, alongside batch resolution and a resident system tray. None of those are incidental. They are the reason the project exists.

The description also mentions scanning a QR code to log in. That is the mechanism for anything a visitor cannot see, and it reuses a Go QR code library rather than asking you to paste a cookie. For a tool whose whole job is pulling media out of a logged-in session, that detail is load bearing.

A Go backend on SQLite with a Vanilla frontend

The feature list spells out the stack. The interface is built with Bootstrap and VanJS, described as light and pleasant to look at, and the backend is written in Go with SQLite for storage, which the author presents as a way to keep building and deploying simple. Concurrency in the browser is managed with p-queue, the JavaScript promise queue, specifically so that batch resolution goes faster than one request at a time.

The dependency list at the bottom of the README is more informative than the feature list. It names the Bootstrap framework, VanJS, Vite, the community-maintained Bilibili API collection, p-queue, a VanJS router, a UUID generator, a cross-platform system tray library, a pure-Go SQLite driver and a QR code generator. Read as a group, that is a deliberate refusal of heavy dependencies: the tray and the database are both chosen to avoid cgo, and the frontend avoids a large framework.

There is one oddity worth naming. The repository's recorded primary language is TypeScript, not Go, even though the README describes the backend as the Go half of the project. The reason is visible in the layout rather than in the prose: the client directory is a Vite frontend and the server directory is a Go module, and the client tree is evidently the larger of the two. A language detector looking at the repository as a whole lands on TypeScript, while anyone reading the README would correctly say the application logic is Go. Both statements are true, and it is a small reminder that the language field on a repository is a guess about proportions, not a description of the architecture.

Reading the changelogs as a record of what mattered

The release history is short and the entries are concrete, which makes it a better guide to the project than any feature matrix would be. Version 2.0.15, published in January 2025, is mostly plumbing: creating the license file, updating the readme, fixing a path error that broke video playback in the Linux browser, and disabling the download button while a download is in flight so it cannot be clicked twice.

Version 2.1.1, published in March 2026, is where the project states its priorities. Every entry is about what ends up in the output file: an option to download video only, an option to download audio only, an audio player mode, a preference for Hi-Res audio when it is available, video metadata support, and a choice of video codec priority. A tool whose releases are named after these six decisions is a tool that has stopped adding surface and started refining results.

The third release complicates the picture slightly. v2.1.2-beta.1 appeared on 2026-08-01, which is after the stable 2.1.1, and its notes are empty. So the most recent downloadable build is a beta with nothing written about it, and the last release anyone can read notes for is over half a year old at the time of writing. The repository's last push was 2026-08-07, close to that beta, which suggests work is still landing even though the stable line has been quiet for a while. Anyone installing should decide deliberately between the two rather than assuming the newest tag is the safest one.

Building from source on two platforms at once

The source build is documented for developers rather than end users, and it assumes both toolchains are present. The frontend is built first, then the Go module is tidied and compiled with cgo enabled:

git clone https://github.com/iuroc/bilidown
cd bilidown/client
pnpm install
pnpm build
cd ../server
go mod tidy
CGO_ENABLED=1 go build

For day to day work there is a shorter pair of steps, one for each half of the project:

# client
pnpm install
pnpm dev
# server
go build && ./bilidown

The cgo requirement is the reason the release path is as elaborate as it is. The project publishes a Docker image, iuroc/cgo-cross-build, whose stated purpose is cross compilation, and the README lists the targets: linux on amd64, windows on amd64, 386 and arm64, and darwin on both amd64 and arm64. Building inside that container is a matter of mounting the checkout and starting a shell, then tagging and invoking goreleaser, which the README notes will run the frontend build and the module tidy automatically.

Compiling without Docker has its own catch. On linux amd64 the build can need three packages, which the README names directly:

sudo apt install pkg-config gcc libayatana-appindicator3-dev

That last one is the tray library, and it is a reasonable signal of how the desktop integration is done: the application lives in a system tray rather than in a conventional window, which is why an indicator development package is a build dependency at all.

The README's advice not to use a proxy

One short note under the other information heading is more operationally useful than most of the rest of the document. The project states that it does not support HTTP proxies, does not recommend using them, and that accessing the service directly from a domestic network improves the success rate and stability of batch resolution. That is a candid admission about where the tool is expected to run, and it is the kind of thing a readme usually omits.

Two other requirements are stated at the top and easy to miss. Users are told to download the build for their system from the releases page, and anyone not on Windows is told to install ffmpeg first. The second point is not a suggestion for muxing later; the project depends on an external binary being present, and the release build bundles a Windows executable that the README asks you to place in the server's bin directory before cross compiling. For a tool that promises up to 8K video and Hi-Res audio, handing the final assembly step to ffmpeg is the standard arrangement, and being explicit about it saves the debugging.

The one part of the interface that has been handed to someone else is macOS. The README lists a third-party native client built on the same backend, maintained separately, and names it as such. That is a good sign for the project's boundaries: the backend is reusable, and the README says who is maintaining the piece you would actually install on a Mac.

What the repository does not tell you

The documentation situation is worth being plain about. There is no documentation site, no wiki and no issue templates mentioned. Everything a new user needs is in the readme, and everything an operator would want, such as where the database file lives or how the tray behaves on a headless machine, is simply not written down. The repository tree is correspondingly thin: a client directory, a server directory, a docs directory holding a screenshot, and the readme and license at the top.

The project has 2,288 stars and 247 forks with 44 open issues, which for a single author utility is a healthy ratio. The topic list is revealing about who it is for: alongside the obvious bilibili, download, video and audio tags sit 8k, 4k, hdr, dolby, hires, flac, mp4 and ffmpeg. Those are the tags of someone who cares about the encode they end up with, not about the interface.

Taken together, this is a well-scoped tool with an unusually honest readme in one respect and an unusually thin one in another. It tells you exactly which links it accepts, which one it does not yet accept, which platforms it builds for, which dependency it needs on which operating system, and where it will work reliably. It does not tell you how any of it is configured at runtime, because there is nothing to configure that the readme bothers to name. That is a fair trade for a utility this narrow, as long as you are willing to read the source when the tray misbehaves.

Editorial conclusion

bilidown is a focused utility rather than a media manager: it resolves four kinds of Bilibili link, lets you pick video, audio or both, and hands the result to ffmpeg. The Go server plus SQLite and the Vanilla frontend are a small, readable codebase, and the release notes show the project spending its effort on output choices rather than on a feature catalogue. What the README does not give you is any documentation beyond itself, and the newest tagged build is a beta, so the sensible starting point is a release download rather than a build from source. Start with the stable v2.1.1 to get the audio and video selection options, and read the proxy note before you try it from outside mainland China.

Frequently asked questions

Official sources

1. Issues
2. iuroc/bilidown on GitHub
3. License: Apache-2.0
4. README
5. Releases