Unzip at 2,040 MB/s
A command-line zip tool for Windows that decompresses every file in an
archive at the same time, one per CPU core. No installer, no graphical
interface — a single 1.54 MB executable you drive from
cmd or PowerShell.
-t changed.
Get started
Three commands cover almost everything
Fzip has no window and no menus. You type a command; it does the work and
prints what happened. Double-clicking fzip.exe shows the help
screen and waits — that is expected, not an error.
1 · Unpack an archive
> fzip x archive.zip
Creates a folder named after the archive, right next to it — not in whatever directory you happen to be standing in.
2 · Look inside first
> fzip l archive.zip
Lists every entry with its size, compression method and whether it is encrypted — without writing anything.
3 · Make an encrypted zip
> fzip a backup.zip MyFolder -p
A bare -p prompts for the password without echoing it, so it
never lands in shell history. You get real AES-256.
Opening a terminal where your archive is
- Open the folder containing the archive in File Explorer.
- Click the address bar, type
cmd, press Enter. - A terminal opens already pointed at that folder. Type your command.
To call it as fzip from anywhere, put fzip.exe in a
folder such as C:\Tools and add that folder to your PATH.
You can also just drag an archive onto fzip.exe in Explorer.
Reference
Every command and option
The complete surface of the tool. Also available as plain Markdown for scripts and assistants.
| Command | What it does | Example |
|---|---|---|
| x | Extract an archive. Output goes to a folder named after the archive, created beside it. | fzip x data.zip |
| l | List the contents: size, compression method, encryption, name. Writes nothing. | fzip l data.zip |
| t | Test integrity. Decompresses and verifies every CRC in memory, writing nothing to disk. | fzip t data.zip |
| a | Create a zip from files and folders. Add -p for AES-256. | fzip a out.zip src docs |
| (none) | Passing just an archive is the same as x. This is what drag-and-drop uses. | fzip data.zip |
| Option | Meaning |
|---|---|
| -o <dir> | Write output to this folder instead of the default. |
| -p [pass] | Password. Give the value inline, or leave it off and Fzip prompts without echoing — which keeps it out of shell history. |
| -t <n> | Number of worker threads. Defaults to every core. |
| -i <glob> | Include only entries matching the pattern. Repeatable. |
| -x <glob> | Exclude entries matching the pattern. Repeatable. |
| -e | Flatten: ignore folder structure and put every file in one place. |
| -y | Assume yes. Needed to overwrite an existing archive when creating one. |
| --overwrite <mode> | all (default), skip, rename or newer — how to treat files that already exist. |
| -mx<0-9> | Compression level for a. 0 stores without compressing, 9 is smallest. |
| --max-memory <n> | RAM ceiling, e.g. 512M or 2G. Default 1G. |
| --no-crc | Skip CRC verification. |
| --progress | Force the progress bar even when output is redirected to a file. |
| -q / -v | Quiet (errors only) / verbose (name every file). |
| -V / -h | Version / help. |
Worked examples
# unpack somewhere specific fzip x data.zip -o D:\output # pull only the images out of a big archive fzip x photos.zip -i "*.jpg" -i "*.png" # unpack again without touching existing files fzip x update.zip -o D:\app --overwrite skip # smallest possible encrypted backup fzip a backup.zip D:\work -mx9 -p # check a download before trusting it fzip t installer.zip
Exit codes, for scripts
| Code | Meaning |
|---|---|
| 0 | Success. |
| 1 | Warning — something was skipped, the rest succeeded. |
| 2 | Error — corrupt archive, wrong password, or could not write. |
| 7 | Bad command line, or the file was not found. |
@echo off fzip x "%~1" -q if errorlevel 2 (echo Extraction failed) else (echo Done)
Why it is fast
One archive, split across every core
A ZIP archive stores each file as an independent compressed block. That means they can all be decompressed at once, rather than queued behind one another. Below is the same 171.7 MB archive and the same binary, with only the worker count changed.
Decompression throughput by worker count
Three and a half times a single worker, levelling off at four. Past that the
whole archive is done in under a tenth of a second, and thread scheduling
costs more than it saves — which is why the last three rows wobble
rather than climb. Measured with fzip t, which decompresses and
verifies without writing to disk; five runs at each count, best taken.
What you actually see on disk
Extracting the same archive to an SSD takes 0.54 seconds —
about 318 MB/s end to end, against 277 MB/s on one worker. Writing
is what sets the pace there, not decompression, which is why the gap almost
disappears. Fzip is fastest where decompression is the bottleneck: many
files, fast storage, or fzip t where nothing is written at all.
One number is never the whole story
Throughput depends on what is in the archive. The figures above come from
documents, which compress well. Run the same binary against an archive that
is two thirds incompressible binary and it verifies at 584 MB/s
instead — still 4.5× what 7‑Zip manages on that same file,
but nowhere near 2,040. Both were measured; neither is the number.
On the harder archive, extraction to disk takes 0.67 s against
tar.exe's 0.82 s and 7‑Zip's 1.79 s. Reproduce
all of it with run_bench.ps1 in the repository.
Formats
What it opens, and what it writes
Zip, done properly
Deflate and stored entries, ZIP64, archives past 65535 entries, UTF-8 and legacy CP437 names, WinZip AES-256/192/128 and legacy ZipCrypto. Version 1.x also read rar and 7z; 2.0 dropped them to do one format well.
Writes zip, encrypted
Parallel deflate with genuine AES-256. Fzip refuses to create legacy ZipCrypto, so a password always means real encryption.
Ignores the extension
Format is read from the magic bytes at the start of the file, so a zip named .rar still opens — and a genuine RAR gets told apart by name, not a puzzling parse error.
Memory stays flat
Entries above 32 MB stream straight to disk. A 200 MB file peaks at 7.5 MB of RAM; a 50 GB one does the same.
Safety
An archiver opens files it did not create
Fzip 2.0 is a rewrite, but not a fresh start on safety: every defect the 1.x audits turned up — thirteen from two audits, five more from the field — came across as a regression test first and a fix second. 66 integration tests and 18 unit tests run against every build.
- Path traversal blocked. Entries with
.., drive letters or absolute roots cannot write outside the destination, and each one is reported by name. - Zip bombs refused. A 199 KB archive claiming 1 KB but holding 200 MB is stopped one byte past what it declared, not after filling the disk.
- Device names renamed. An entry called
CONorNULbecomes_CON— files named after a device are nearly impossible to delete. - Long paths work. Past 260 characters Fzip writes through the extended form, and never reports success for a file it failed to create.
- Encrypt-then-MAC. AES entries are authenticated before decryption, so tampered data is rejected instead of decoding into garbage.
- CRC on every entry by default, hardware-accelerated so it costs almost nothing.
- Nothing privileged in the import table. No
AdjustTokenPrivileges, no process injection, no registry writing. Five system DLLs, and the C runtime is linked in rather than imported, so there is no Visual C++ Redistributable to install. - Hardened binary. Control Flow Guard, ASLR, DEP and high-entropy address space, with a full application manifest. Section entropy 6.31 — ordinary compiled code, never packed or obfuscated.
- Reviewed by Microsoft. This build was submitted to Microsoft Security Intelligence, analysed, and allow-listed; SmartScreen passes it. Earlier releases drew a machine-learning false positive, and what was measured is published rather than hidden.
Download
Two files. Take the one that fits.
The same program, built twice. They differ by a single field in the executable header — whether Windows gives the process a console. That one flag decides whether you can see what happened, or whether a black window flashes on your users' screens. No runtime, no DLLs, no registry entries either way.
fzip.exe
For people. Take this one unless you are writing an installer.
Has a console, so you see the progress bar, the summary and any error.
Double-click it and the help screen appears; drag a .zip onto
it and it unpacks beside the archive. Windows 10 and 11, 64-bit.
1,612,288 bytes.
It reports version 1.3.0, and that is deliberate. This file has not been rebuilt since Microsoft reviewed and allow-listed it, and that clearance follows the exact bytes — recompiling it to bump a number would throw it away for nothing.
fzipw.exe
For installers. MSI custom actions, WiX, services, scheduled tasks.
No console is ever allocated, so no window can flash — the complaint that made this file exist. Same options, same exit codes, same archives. It prints nothing unless you redirect, because there is nowhere for output to go. Windows 10 and 11, 64-bit. 1,613,312 bytes.
Which one, and the catch with the quiet one
| Launched by | fzip.exe | fzipw.exe |
|---|---|---|
| A person, in a terminal | output, progress bar | nothing visible |
| Double-click in Explorer | help screen, then waits | nothing at all |
| MSI custom action, service | console flashes | silent, always |
| Exit codes | yes | yes |
PowerShell does not wait for fzipw.exe. Measured:
& fzipw x big.zip -o out returned after 9 ms having extracted
nothing, and $LASTEXITCODE meant nothing. That is inherent to a
process with no console, not something the program can fix from the inside. Ask
for the wait and it behaves:
PS> Start-Process fzipw -ArgumentList x,a.zip,-o,out -Wait -PassThru PS> fzipw x a.zip -o out | Out-Null PS> cmd /c fzipw x a.zip -o out
MSI custom actions, Task Scheduler and .NET's Process.WaitForExit
all wait correctly on their own — they hold the process handle. The
caveat only bites when you call it from a shell.
If you write the WiX yourself you may need neither file.
WixQuietExec, in WixUtilExtension, runs a console
program with CREATE_NO_WINDOW and no window appears.
fzipw.exe is for when you do not control the caller.
Check it before you run it
PS> Get-FileHash fzip.exe -Algorithm SHA256 PS> Get-FileHash fzipw.exe -Algorithm SHA256
Each hash above identifies one published binary. Fzip is not code-signed: the files are vouched for by those hashes and by source you can read and rebuild, not by a certificate. That is stated plainly because a claim of a signature you cannot verify is worse than no claim at all.
Compiling the source yourself gives a functionally identical executable with a
different hash, because Rust builds are not bit-for-bit reproducible —
expected, not tampering. Every dependency is pinned in Cargo.lock,
and there are fourteen of them, each reachable from code Fzip actually runs.
Limits
What Fzip will not do
Said up front, so nothing surprises you later.
- Zip only. Fzip 1.0 also read rar, 7z, tar, gz, bz2, xz and zst. Those are gone. If you need them, keep a tool that has them — Fzip will at least tell you which format you handed it.
- Windows only. The console handling and path rules are written directly against the Win32 API; there is no portable build.
- No graphical interface, no shell integration, no self-extracting archives. It is a command-line tool, by design.
- Uncommon zip methods unsupported: BZip2, LZMA, Zstd, XZ and Deflate64 inside a zip are reported clearly rather than mis-extracted. Deflate and stored cover essentially everything in the wild.
- Encrypted entries are buffered, not streamed. The authentication code covers the whole entry, so it has to be held in memory to be verified before decryption.
--max-memorysets the ceiling.