# yt-dlp-tauri pins its own yt-dlp, ffmpeg and deno revisions instead of trusting your PATH > A Windows-only Tauri 2 wrapper around yt-dlp that downloads and hash-verifies its own copies of yt-dlp, ffmpeg, ffprobe and deno as versioned releases, then stages them before activating them. The pinning discipline is the interesting part; the platform scope and the fact that you can also point it at arbitrary local executables are the costs. **Chlience/yt-dlp-tauri** — A minimal Windows desktop downloader powered by yt-dlp and Tauri 2. / 基于 yt-dlp 和 Tauri 2 的轻量 Windows 桌面下载器。 - Repository: https://github.com/Chlience/yt-dlp-tauri - Stars: 420 · Forks: 27 - Language: JavaScript - License: GPL-3.0 - Published: 2026-09-20 · Updated: 2026-09-20 · Language: en - Canonical page: https://hysenlabs.com/projects/chlience-yt-dlp-tauri ## The toolchain is a build artifact, not a dependency you resolve Most GUI wrappers for a command-line downloader leave you to install it first and hope the versions line up. This one treats the toolchain as something the project ships. `toolchain-policy.json` holds the reviewed upstream sources, the version-selection rules, the targets and the allowed hosts; `toolchain-lock.json` holds the chosen upstream identity, immutable archive descriptors and SHA-256 hashes for both archives and executables; `src-tauri/tools-manifest.json` holds the runtime revision, the project-controlled archive URLs, target names and executable hashes. Three generated files describe the same four binaries, and `TOOLCHAIN_CHANGELOG.md` tracks tool-only revision history separately from application releases, so a tool bump does not need an app release to go with it. Nothing binary sits in the repository. The supported target is `win-x64` and only that target. Installed revisions land under `%LOCALAPPDATA%\yt-dlp-tauri\Tools\win-x64\revisions\\` with an `active.json` pointer beside the directory, which is what makes rolling a tool revision back a matter of pointing at a different revision rather than reinstalling anything. ## Two workflows, a weekly batch and a daily emergency patch Automation is split by how urgent the change is. `Toolchain Discovery` resolves yt-dlp, Deno, FFmpeg and FFprobe once a week and maintains a single reviewed `bot/toolchain-weekly` pull request, so the weekly churn arrives as one reviewable diff instead of a stream. `Toolchain Freshness` checks released source URLs daily and opens a focused emergency pull request for whichever source moved. Neither merges on its own; both require human review. Merged changes pass native validation before publication to a separate `yt-dlp-tauri-toolchain` archive, and the app follows a `toolchain-stable` channel. The resolver that ties policy, lock, manifest and changelog together can be run locally without writing files: ```bash GITHUB_TOKEN="$(gh auth token)" node scripts/update-toolchain.mjs --dry-run ``` That dry run is the cheapest thing in this repository to audit. Source and selection changes belong in `toolchain-policy.json`, and the resolver regenerates the lock, the runtime manifest and the toolchain changelog in one pass, so a reviewer sees the whole consequence of a policy edit before it reaches a build. ## Staging before activation, and what local mode gives up Every tool is staged and verified before atomic activation, and the preserved behaviour is the part worth having: when an update fails, the active revision stays put instead of leaving you half a toolchain. Local tools are held to the same bar. Switching to a PATH-resolved `yt-dlp.exe`, `deno.exe` and one directory containing both `ffmpeg.exe` and `ffprobe.exe` triggers their version commands plus the same deterministic media compatibility fixture used for managed revisions, so a local install can fail the app's compatibility check even though the binaries run fine on their own. Local mode deliberately stops there. No hashes are pinned, no updates are installed, no executables are replaced. The trade is stated plainly: local programs run with your permissions, and the selected yt-dlp executable receives your video URLs and your Cookie file. Point this at an untrusted binary and you have handed it both. `Use PATH` clears the absolute-path overrides and resolves everything from PATH again. Nothing published explains what Deno is for in a downloader. It is resolved, hashed, staged and verified like the other three, and it appears in the policy, the lock and the manifest, but no file in this repository assigns it a role. That is the first entry to ask about when auditing the chain. ## Cookies mean authenticated downloads and a credential file on disk Cookie support covers Netscape `cookies.txt` and one-line browser Cookie headers, which is how the app reaches sites that require a login. The flip side is that a credential file lands on the machine and gets handed to whichever yt-dlp executable is configured, managed or local. This is the security surface of the whole project and it is not a defect: authenticated downloads are the reason many people reach for yt-dlp at all. The paths involved are ordinary Windows locations. Downloads default to `%USERPROFILE%\Downloads\yt-dlp-tauri\`, app state and logs to `%LOCALAPPDATA%\yt-dlp-tauri\state\` with the log at `%LOCALAPPDATA%\yt-dlp-tauri\logs\app.log`, and the tool source choice plus any absolute-path overrides to `%LOCALAPPDATA%\yt-dlp-tauri\state\toolchain-source.txt` and `%LOCALAPPDATA%\yt-dlp-tauri\state\local-toolchain.json`. The cookie path itself is picked in Settings and is not written into any of these files. ## win-x64 only, and the installer is the whole distribution story The build target is a single one. `src-tauri\tauri.conf.json` sets the bundle target to `nsis` and the installer to Windows x64, and the release scope covers one tool target and nothing more. Anyone on macOS or Linux has no packaged application, and there is no server component to fall back on: it is not a hosted downloader service, it offers no multi-user accounts, and it is not affiliated with yt-dlp, FFmpeg, Deno or Tauri. Building from source needs Windows 10/11 x64 with the WebView2 Runtime, Node.js 24 or later, Rust stable with the platform toolchain, and PowerShell 5 or 7. WSL can run many checks, but real installers are meant to come from Windows or the GitHub Actions release workflow. ```powershell npm ci ``` That installs three runtime dependencies (`@tauri-apps/api`, `@tauri-apps/plugin-dialog`, `@tauri-apps/plugin-opener`) and four dev dependencies including TypeScript 5.6 and Vite 6. Development tools are a separate, optional step: ```powershell .\scripts\download-tools.ps1 ``` It restores the pinned `win-x64` toolchain into the checkout. Skipping it is fine for normal use: open the app, go to Settings and click `Install tools` instead. ```powershell npm run tauri dev npm run tauri build ``` The first runs the desktop app under Vite. The second writes the NSIS installer under `src-tauri\target\release\bundle\nsis\`. The `test` script hands the TypeScript files under `tests/` to Node's own runner with type stripping switched on, so the suite needs a Node build that can strip types, not just the Node 24 floor stated for development. ## A fixed-size window with no documented way to pass extra yt-dlp options The interface is a fixed-size product-style desktop window, sized in `src-tauri\tauri.conf.json`, and it switches between English and Chinese. What it shows is a preview first: title, thumbnail, duration, source URL, description and quality options, all parsed through yt-dlp. During a download it shows live progress, speed and ETA, with cancellation and a saved output folder behind the Settings controls. That list is also the boundary. The README documents no way to pass arbitrary yt-dlp options, no format selector beyond the quality choices, and no handling for playlists, subtitles or per-site post-processing. The moment a download needs an unusual yt-dlp flag, the answer is not in the window, and whether some other screen exposes it is not stated in any file here. Settings carries the rest of the surface: an output folder with select, save, reset and open actions, a GitHub site switch between `Direct` and `gh-proxy` for update checks and release links, and the tool source toggle. The proxy choice covers updates and releases only, since the project home always opens GitHub directly. Application updates are checked against GitHub Releases, and the same `gh-proxy` route serves tool downloads. ## The v0.1.11 flat tool directory, and a canary file nobody explains One migration seam is left open. The v0.1.11 flat tool directory stays readable until the first revision is successfully activated, so an app crossing that boundary can still find its tools until the new layout is proven. The same tolerance is not extended anywhere else, and it is worth knowing which mechanism you are leaning on before an upgrade. Development checkouts can also carry tools in the tree at `src-tauri\Tools\win-x64\yt-dlp\yt-dlp.exe` and an ffmpeg location beside it. The published README cuts off mid-line while listing those development paths, so the exact ffmpeg path is not fully readable from the file itself. The installed-layout paths are complete. `toolchain-canary.json` sits at the repository root next to the policy and lock files, and the maintenance section never says what it controls or who reads it. The documented automation is exactly two workflows, the weekly `bot/toolchain-weekly` pull request and the daily freshness check, so a reader hunting for the canary's place in that chain will not find it in the documentation. ## v0.1.13 shipped in July, the commits kept going into September The last push was on 2026-09-28. The three most recent releases are v0.1.13 from 2026-07-14, v0.1.12 from 2026-07-13 and v0.1.11 from 2026-06-24, and `package.json` matches the newest tag at version 0.1.13, so the version and the release line agree with each other. They do not agree with the commit line: roughly eleven weeks of commits separate v0.1.13 from the last push. That gap has a concrete consequence here. Because tool revisions travel on their own channel and in their own changelog, much of what lands between two application releases is tool work, and an installed build is a July application shell around whatever revision was current when it installed. Anyone debugging a site that stopped parsing wants `TOOLCHAIN_CHANGELOG.md` first, not the app version. Licensing is GPL-3.0, with `package.json` spelling it `GPL-3.0-only` and the repository shipping a `LICENSE` file next to `THIRD-PARTY-NOTICES.md` and `SECURITY.md`. That is the one adoption question here with no nuance. GPL-3.0-only carries distribution obligations that MIT-licensed wrappers do not, so read it against how you intend to ship anything built on this before you build on it. ## Conclusion Adopt it if you want one fixed Windows desktop path to yt-dlp with pinned tools, a reversible local mode and no account. Skip it on macOS or Linux, or if you need yt-dlp features this GUI does not surface. Before trusting an install, confirm the bundled revision under %LOCALAPPDATA%\yt-dlp-tauri\Tools\win-x64\ matches what your sites need, since the latest application release (v0.1.13, 2026-07-14) shipped well behind the last push on 2026-09-28. ## FAQ ### Is the yt-dlp build that yt-dlp-tauri ships free to use? The wrapper is GPL-3.0, recorded as `GPL-3.0-only` in `package.json` with a `LICENSE` file at the repository root. The four tools it installs (yt-dlp, ffmpeg, ffprobe, deno) arrive as project-controlled GitHub Release assets and are not committed to the repository. ### Can yt-dlp-tauri run my own yt-dlp instead of the one it manages? Yes. Settings switches the whole toolchain between `Managed` and `Local`, resolving `yt-dlp.exe`, `deno.exe` and a directory holding both `ffmpeg.exe` and `ffprobe.exe` from the current process PATH, or from absolute paths you select. Local tools are checked with their version commands and the same media compatibility fixture, but no hashes are pinned and nothing is updated or replaced. ### Where does yt-dlp-tauri keep the tools it installs on Windows? Installed revisions go under `%LOCALAPPDATA%\yt-dlp-tauri\Tools\win-x64\revisions\\`, with the active revision recorded in `%LOCALAPPDATA%\yt-dlp-tauri\Tools\win-x64\active.json`. Videos default to `%USERPROFILE%\Downloads\yt-dlp-tauri\`, and the app log is `%LOCALAPPDATA%\yt-dlp-tauri\logs\app.log`. ### Does yt-dlp-tauri work outside Windows? No packaged build exists for other platforms. The bundle target is `nsis` for Windows x64, the supported tool target is `win-x64` only, and the documented prerequisites are Windows 10/11 x64 with the WebView2 Runtime. WSL can run many checks, but installers are meant to be built on Windows or by the release workflow. ### What happens when a yt-dlp-tauri tool update fails halfway? Tools are staged and verified before atomic activation, and a failed update preserves the active revision rather than leaving a partial toolchain. The v0.1.11 flat tool directory also stays readable until the first revision is activated successfully. ## Sources - [Chlience/yt-dlp-tauri on GitHub](https://github.com/Chlience/yt-dlp-tauri) - [Issues](https://github.com/Chlience/yt-dlp-tauri/issues) - [License: GPL-3.0](https://github.com/Chlience/yt-dlp-tauri/blob/main/LICENSE) - [README](https://github.com/Chlience/yt-dlp-tauri/blob/main/README.md) - [Releases](https://github.com/Chlience/yt-dlp-tauri/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chlience-yt-dlp-tauri