I deleted a 4 GB video file three times before I admitted my browser's download bar was lying to me. The progress hit 99% and then froze, and the only fix was to start over from zero. I built Snatch as my answer to that particular brand of frustration.
Snatch is a download manager for Linux, written in Rust, with a native GTK4 and libadwaita interface. It takes one URL, splits the target file into 16 pieces, fetches those pieces at the same time, and stitches them back together when every part lands. When a connection drops, it resumes from the exact byte it lost instead of restarting the whole job.
The tagline says it plainly: a fast download manager for Linux built on GTK4. Version 2.7.3 is source-available and lives at github.com/ayoubzulfiqar/snatch-dl. This case study explains how I designed it, where it beats the browser, and where it still falls short.
Key Takeaway
Snatch wins by doing less itself. It owns the window and the schedule, then hands the actual fetching to proven single-purpose tools running as their own unprivileged processes.
What is Snatch and who built it?
Snatch is a download manager, not a browser add-on and not a command-line wrapper you script by hand. The interface is a real desktop window drawn with GTK4 and libadwaita, so it matches the look of native GNOME apps on Linux.
I wrote it because every manager I tried either lacked a proper Linux UI or tried to do too much in one privileged process. Snatch takes the opposite stance. The Rust core stays small and the heavy lifting goes to tools that already do one job well.
This case study covers release 2.7.3 (the latest is 4.16.0). The code is source-available under the Snatch Source-Available License 1.0: you can read and build it, but forking or redistributing modified versions needs permission. The external tools it drives keep their own licenses.
Why does a Linux download manager need to split files into 16 parts?
Most servers cap how fast a single connection can pull data. One stream hits that ceiling and stops, even when your link has room left.
Splitting a file into 16 pieces lets Snatch open 16 connections to the same server. Each connection grabs its own slice, so the combined speed climbs well past what one stream could manage. On a fat connection the difference is the gap between a stalled bar and a finished file.
The split also builds in resilience. If one part fails, Snatch re-fetches only that slice. The other 15 keep moving, and the job finishes without a full restart.
How does Snatch grab a file from 16 places at once?
Snatch hands the actual transfer to aria2, the multi-protocol download utility that already knows how to chunk a file and pull ranges in parallel. Snatch asks for 16 parts, points aria2 at the URL, and watches the progress.
When the network drops, aria2 reports the last good byte. Snatch records it and, on reconnect, requests the file from that offset forward. It resumes exactly where it stopped.
We first tried to call aria2 as a bundled library inside the same process. One bad tracker froze the interface for 40 seconds and took the whole window down with it. The fix was to push aria2, librqbit, and the rest into their own unprivileged processes and talk to them over a local Unix socket.
How does Snatch compare to a browser download?
The browser is a fine place to click a link. It's a poor place to manage a large, fragile transfer.
| Capability | Browser download | Snatch |
|---|---|---|
| Parallel parts | One stream per file | 16 parts fetched together via aria2 |
| Resume after drop | Often restarts from zero | Resumes at the exact lost byte |
| Torrents | Not supported | Built-in engine via librqbit |
| Video and galleries | Manual, one link at a time | yt-dlp and gallery-dl scraping |
| Whole-site grabs | Not supported | Wget2 mirroring from one window |
| Cookies and auth | Handled by the browser | Browser bridge carries cookies over |
| Checksum and extract | Not built in | Verifies and auto-extracts archives |
The browser wins on convenience for a 2 MB PDF. Snatch wins the moment the file is large, the link is flaky, or you want more than a plain HTTP fetch.
What engines does Snatch drive under the hood?
Snatch is an orchestrator. It launches each specialist as a separate unprivileged process and coordinates them over a local Unix socket.
aria2 pulls HTTP, HTTPS, and FTP with multi-part ranges. librqbit runs the torrent side and supports sequential playback so you can watch while the swarm fills the rest. yt-dlp grabs video and audio from hosted platforms. gallery-dl scrapes image galleries. Wget2 mirrors whole sites. ffmpeg post-processes media, and 7-Zip unpacks archives after a checksum passes.
None of these run as root. Snatch spawns them with the rights of the logged-in user and talks to them through the socket. That design keeps a bad download from escalating into a system-level event.
How does the browser bridge catch downloads before the browser starts them?
The snatch-nmh extension watches the browser for a download about to begin. It intercepts the request and hands the URL, along with the page's cookies, to the Snatch desktop app.
This matters for sites that gate files behind a login. The cookie proves you're signed in, so Snatch fetches the file with your session instead of failing on an auth wall. The browser never starts its own slow single-stream transfer.
The bridge carries cookies only for the download it intercepts. It doesn't sit between you and every page you visit.
How does Snatch compare to single-threaded managers?
Older managers queue one stream per file. Snatch opens 16.
| Trait | Single-threaded manager | Snatch |
|---|---|---|
| Speed on a fast link | Capped at one stream | 16 parallel parts |
| Crash isolation | One fault can kill the app | Separate unprivileged processes |
| Privilege model | Sometimes asks for root | Never runs sudo |
| Engine breadth | HTTP only | aria2, librqbit, yt-dlp, gallery-dl, Wget2, ffmpeg, 7-Zip |
| Scheduling and limits | Basic queue | Scheduled, throttled, proxy-aware |
The single-threaded approach is simpler to reason about. Snatch trades that simplicity for speed and a smaller blast radius when one engine misbehaves.
What can Snatch do and what can't it do?
Here is the honest split between what the tool handles and what it refuses or can't reach.
| Capability | Can | Cannot |
|---|---|---|
| Split and parallel fetch | Split a file into 16 parts | Exceed the per-connection limit the server enforces |
| Resume | Resume from the exact lost byte | Recover a file the server already deleted |
| Torrents | Seed and play sequentially via librqbit | Replace every flag of a dedicated torrent client |
| Video and audio | Grab with yt-dlp | Bypass paywalled DRM streams |
| Galleries | Scrape with gallery-dl | Log in to sites needing 2FA beyond the cookie bridge |
| Whole sites | Mirror with Wget2 | Crawl pages behind heavy JavaScript auth |
| Security model | Run as an unprivileged user | And will not run sudo under any flag |
Is Snatch safe to run with root or sudo?
No, and that's by design. Snatch never calls sudo and never asks for root.
Every engine runs as a separate unprivileged process under your normal user account. The local Unix socket stays on your machine and isn't exposed to the network. A compromised download can trash your files, but it can't escalate to system control through Snatch.
If a package or guide tells you to run Snatch with sudo, that instruction is wrong. The tool is built to avoid exactly that.
How do I schedule, throttle, and proxy downloads in Snatch?
Snatch queues jobs and lets you set a start window, so a big pull can wait until off-peak hours. You pick the time and the app wakes the transfer on its own.
Throttling caps the bandwidth a job uses. That keeps a 20 GB mirror from choking the rest of your network while someone else is on a video call.
Proxy awareness routes traffic through the gateway you configure. For sites that block by region or require a specific egress, point Snatch at the proxy and the engines follow.
What are the challenges and limitations of Snatch?
Snatch is Linux-only today. The GTK4 and libadwaita interface assumes a Linux desktop, so there's no native Windows or macOS build in 2.7.3.
It depends on external engines being installed. If aria2 or yt-dlp isn't on your system, that part of the feature set stays dark until you add it.
The 16-part split only helps when the server supports ranged requests. A host that serves a file as one unbreakable stream gets no speed gain from splitting.
Cookie-based auth works through the bridge, but sites that demand interactive 2FA or solve-a-captcha gates will stop Snatch cold. It catches downloads; it doesn't solve login walls for you.
The Unix socket model is local by default. If you want remote control, you have to expose it yourself, and that's a choice with real security cost.
How does Snatch compare to other download managers?
Most managers pick one lane. They do HTTP well, or they do torrents well, or they scrape media well, but rarely all three from a single window.
Snatch's edge is breadth without privilege. It pulls the same engines a power user would script by hand and wraps them in a GTK4 window that talks to each over a socket. You get aria2 speed, librqbit torrents, and yt-dlp scraping without writing a line of shell.
The trade is setup honesty. Snatch is a coordinator, so it shines when the underlying tools are present and the server cooperates with ranged requests.
FAQ
Is Snatch free and open source?
It's free to download and the source is public, but it isn't open source. Since 2.7.0, Snatch uses the Snatch Source-Available License 1.0, which lets you read the code but requires permission to fork it. The tools it drives (aria2, yt-dlp and the rest) keep their own licenses.
Which Linux distributions support Snatch?
Any Linux desktop with GTK4 and libadwaita support. The app is built for the Linux desktop and isn't packaged for Windows or macOS in this release.
Does Snatch need root access?
No. It never runs sudo and spawns every engine as an unprivileged process under your user account.
Can Snatch download torrents?
Yes. It uses librqbit as a built-in engine and supports sequential playback so you can watch while the file completes.
How does the browser bridge work?
The snatch-nmh extension intercepts a download before the browser starts it and passes the URL plus the page's cookies to the desktop app.
Does Snatch verify file integrity?
Yes. It computes checksums and can auto-extract archives once the verification passes.
Can I schedule downloads?
Yes. Jobs can wait for a set window, throttle their bandwidth, and route through a configured proxy.
Which engines does Snatch call?
aria2 for HTTP/FTP, librqbit for torrents, yt-dlp for video and audio, gallery-dl for image sets, Wget2 for site mirrors, ffmpeg for media, and 7-Zip for archives.
What version is current?
This case study covers release 2.7.3. The latest release is 4.16.0; see the GitHub releases page for current builds.
Where is the source code?
At github.com/ayoubzulfiqar/snatch-dl, published under the Snatch Source-Available License 1.0.
Does Snatch handle captcha or login walls?
No. The cookie bridge covers session auth, but interactive 2FA and captcha gates will stop a transfer.
Can Snatch throttle bandwidth?
Yes. Each job can cap its speed and route through a proxy you set.