DownVid wraps yt-dlp and FFmpeg in an Electron desktop app

A GUI over two binaries you would otherwise install yourself

DownVid is an open source desktop video downloader for macOS, Windows and Linux, built as a graphical front end for yt-dlp and FFmpeg. The stated purpose is to remove the complexity of command line tools and offer a clean, native, ad-free experience.

That framing sets the scope precisely. DownVid does not implement extraction. It drives yt-dlp for the retrieval and FFmpeg for the media work, and the site coverage follows from yt-dlp rather than from anything in this repository. The README advertises support for more than a thousand platforms, naming YouTube, Bilibili, Douyin, TikTok, Xiaohongshu, Kuaishou, Twitter/X and Instagram among them, and notes that Douyin and Kuaishou have dedicated parsers in the project itself.

The project is also explicit about its own legal position, and it is worth quoting the spirit of it. A prominent note states that DownVid is a graphical front end for yt-dlp, that it contains no code for cracking or circumventing technical protection measures, and that users should follow local laws, platform terms and copyright requirements, being responsible for how they use it. That is a narrower claim than the marketing language elsewhere on the project page, and it is the claim the code can support.

The desktop build is an Electron shell with a Vue 3 interface, packaged with electron-builder from a json5 configuration, and the repository also carries a backend, a shared package, a website and a docker directory, so the same application exists as a desktop app and as a server you reach through a browser.

The sidecar finds or fetches yt-dlp and FFmpeg

The feature that most affects daily use is described in the README as a zero-config sidecar. It automatically detects existing system tools, or downloads and manages standalone yt-dlp and FFmpeg binaries in isolated user storage.

Both halves of that sentence matter. Detection means a user who already has yt-dlp on their PATH does not have to install anything else, and the app does not duplicate it. The fallback matters more: a user with no tooling installed gets working binaries without a second installation guide, and the binaries live in the app's own storage rather than being written into system directories.

The wording about isolation also hints at the update path. Since these binaries are third-party tools that change often, keeping them in user storage means they can be replaced without touching the operating system, and a broken upgrade can be rolled back by putting the previous file back. The README does not document a rollback procedure for that, so anyone relying on it should confirm the behaviour before depending on it.

The download engine is described separately, with optimised multi-part chunk worker queues of up to 16 threads and optional aria2 integration. The practical meaning is that large files are fetched in parallel parts and reassembled, and a user who prefers an external download manager can hand the transfer to aria2 instead of using the built-in queue.

Format choices go down to 360P, 4K, MP3 and SRT

The feature table in the README lists what can be selected once a URL is known. Formats run from 360P through 4K, with audio-only output as MP3 and subtitles-only output as SRT, and multi-audio tracks are listed for YouTube.

The last item is the one that changes the character of the tool. Multi-audio support means a single video can yield several separate audio streams rather than one mixed track, which is the difference between a downloaded clip and a usable track for listening or editing. The subtitle-only option is the complementary case: sometimes what you want from a video is the text, and a separate SRT file is more useful than the container.

Because the format list is really a projection of what yt-dlp reports for a given URL, the option list is not uniform across sites. That is a property of the underlying extractor rather than a flaw in the interface, but it means the dropdown contents depend on the site and change when yt-dlp is updated. A user building a repeatable workflow should treat the format list as site-specific rather than universal.

Other entries in the feature table cover the parts of the job that are not about the bytes: the download manager with its queue, and the options around what happens to the finished file.

The container runs the same app behind a port

The repository ships a Docker deployment in addition to the desktop app, and the compose file in the root is a thin entry point with the real configuration in the docker directory. The service runs from the official multi-architecture image on GHCR:

    image: ${DOWNVID_IMAGE:-ghcr.io/downvid/downvid:latest}

The port mapping is configurable, with the container port fixed at 6080:

    ports:
      - "${DOWNVID_HTTP_PORT:-6080}:6080"

Three directories are mounted, and the environment variables inside the container are named for the same paths, which keeps the data layout explicit rather than implicit:

    environment:
      DOWNVID_HOME: /data
      DOWNVID_DATA_DIR: /data/userdata
      DOWNVID_DOWNLOADS: /data/downloads
      DOWNVID_WEB_HOST: 0.0.0.0

The healthcheck calls the health endpoint on the same port with curl, and the compose file notes that the image already carries a healthcheck, with the override only widening the startup wait because the first run has to unpack dependencies. There is also an update source setting, and the comment next to it is candid about why: the image name is not hard-coded in the image so that the user can change the channel, whether that is auto, github, jsdelivr, ghproxy, gitee or website. The update check asks the registry whether a newer digest exists.

Running this on a server means exposing an interface that downloads files from arbitrary sites, so the host and port configuration deserve attention before it is put on a public address.

One manifest, three platform builds

The build story is visible in the root package.json, where the scripts are one per target platform and share a common shape. The general build type-checks with vue-tsc, bundles with Vite and packages with electron-builder against electron-builder.json5:

    "build": "vue-tsc && vite build && electron-builder --publish never --config electron-builder.json5",
    "build:mac": "vue-tsc && vite build && electron-builder --mac --publish never --config electron-builder.json5",
    "build:win": "vue-tsc && vite build && electron-builder --win --publish never --config electron-builder.json5",
    "build:linux": "vue-tsc && vite build && electron-builder --linux --publish never --config electron-builder.json5",

Architecture is a separate axis rather than a separate script family. The mac build comes in arm64 and x64 variants, and the Linux build has an x64 variant plus two packaging formats, AppImage and deb:

    "build:mac:arm64": "vue-tsc && vite build && electron-builder --mac --arm64 --publish never --config electron-builder.json5",
    "build:linux:x64:appimage": "vue-tsc && vite build && electron-builder --linux AppImage --x64 --publish never --config electron-builder.json5",

The toolchain constraints are declared in the same manifest, with Node 22 or newer and pnpm 8 or newer required, and pnpm 11.0.0 pinned as the package manager. A pnpm workspace file, a pnpm lock file and a vitest configuration sit alongside, and the repository root also carries separate tsconfig files for the app and for the Node side of the build.

The overall shape is a monorepo that contains more than the desktop app. There are app, backend, shared, website and docker directories, plus a build directory, scripts and tests, which is consistent with a project that ships the same product in a desktop and a server form from one tree.

MIT terms, weekly releases, and CI on three platforms

The licence is MIT, with a LICENSE file at the root and a TRADEMARKS.md alongside it, plus a SECURITY.md for responsible disclosure and a CODE_OF_CONDUCT.md. The README states the intention plainly: the app contains no ads and never will, and sponsorship enquiries are about the project, such as a placement in the README or on the website, rather than anything shipped inside the installer.

Activity is recent and the release line is moving quickly. The last push was on 2026-10-19, and three releases landed in the same week: v1.5.0 on 2026-10-18, v1.4.0 on 2026-10-16 and v1.3.4 on 2026-10-14. The version in the root package.json reads 1.5.0, matching the newest tag. There is a CHANGELOG.md in the repository for the detailed history.

Continuous integration is visible in the README badges, which point at separate workflows for Linux, macOS and Windows, plus a CodeQL workflow. Three platform-specific pipelines for a desktop application is the minimum sensible arrangement, since an Electron build that packages on Linux but not on Windows is a build failure that only the user would discover.

The one thing the project does not promise is stability of any particular site. DownVid inherits yt-dlp's coverage, and a site that changes its page structure breaks extraction until the upstream extractor is updated. Since the sidecar manages the yt-dlp binary itself, that update can reach the user without a new DownVid release, which is the reason the sidecar design matters more than it first appears.

Editorial conclusion

DownVid suits someone who wants to save a video from a site yt-dlp supports without learning its flags, and who is comfortable with a desktop app that manages its own helper binaries. It is the wrong tool when a one-off command would do, since the same work is a single yt-dlp invocation, and it is the wrong tool for anything that needs to defeat access controls, which the project explicitly says it does not attempt. Before you adopt it, check the licences of the sites you intend to download from, since the project puts that responsibility on the user, look at the update source setting in the container deployment, because the image name is what the upgrade command echoes back, and verify that the yt-dlp binary the app downloads is one you are willing to run on your machine.

Frequently asked questions

Official sources

1. Downvid/downvid on GitHub
2. License: MIT
3. Project website
4. README
5. Releases