It started as a small annoyance
Every time I extracted a file on Windows, I'd get an ad, a nudge to pay, and a "new version available" popup on top of it. Five seconds to extract, twenty to close all the windows. You've probably been there.
Why isn't there a Windows archiver that just quietly does the job? The Mac has Keka. That thought stuck with me until I finally started building one. I called it OtterZip.
The idea: open the app as little as possible
The thing I liked most about Keka was that I almost never opened the app — compressing and extracting both happened right in Finder. I wanted that feeling on Windows.
So OtterZip's default flow is:
- Right-click a file → compress
- Right-click an archive → extract
- Drag files or folders onto the app → it compresses/extracts automatically
Most of the time you never open a window. I think the best archiver is one you forget is there.
No ads, no account, no tracking
This is more of a stance than a feature. OtterZip has no ads, no account to create, and it doesn't quietly collect usage data. No bundled software riding along with the installer either.
And rather than ask you to take my word for it, I made the whole thing open source (GPL-3.0). If the "no tracking" claim is something you can verify in the source, and the parser that opens untrusted files is right there to audit — that, to me, is what open source is actually for.
Speed wasn't up for negotiation
For an archiver, speed is the one thing you shouldn't trade away, so it was a priority from day one.
For the heavy codecs I didn't insist on a pure-Rust reimplementation — I used the same battle-tested C libraries everyone else does (libdeflate, zstd, liblzma). The rule was simple: if something faster exists, use it. On top of that the core does parallel extraction and smart-store, so it keeps pace with the fast Windows archivers in my testing. (It varies by machine, so I won't claim it's "the fastest in the world" — throw a big file at it and measure for yourself; that's the only honest answer.)
Why three languages — Rust + C + C#?
Using three instead of one was deliberate. Each does what it's best at.
- Rust — the core. The part that actually reads and writes archives. It opens untrusted files, so getting memory safety for free matters a lot. Path-traversal, zip-bombs and malformed headers are all handled here.
- C — speed. The codec libraries above. Anywhere performance is on the line, I reach through a C ABI instead of holding out for pure Rust.
- C# / WinUI — the surface. The UI is native — not a web view in a window — so first launch is light. Dark mode and ten languages.
It's not perfect (and I'd rather not hide that)
There's one thing I haven't fully cracked. Right after a reboot, the very first right-click sometimes doesn't show the menu (a second one does). It's a cold-start issue with packaged (MSIX) shell extensions, and digging in, it turns out to be something app code can't fully fix. NanaZip has it, and even Windows Terminal ran into the same thing.
The fun part: when I aired this publicly, I got help instead of grief. One person pointed out that our verb identifiers (GUIDs) were still placeholders — which let me clean up a future collision before it happened — and another helped confirm it's ultimately an explorer.exe problem. For a solo project, moments like that are what keep it going.
Give it a try
- It's Windows x64 for now; macOS is planned on the same core.
- RAR is extract-only (RARLAB's unRAR licence won't let me ship a RAR creator).
- The direct download is free; there's a paid Store listing as a way to chip in, but it's the exact same app.
If you hit a file it won't open, please file a GitHub issue — I'll go through them gladly.
- Free download — https://lumibearstudio.github.io/otterzip-web/
- Source — https://github.com/LumiBearStudio/OtterZip
Top comments (0)