Windows 11 ZIP speed benchmark: built-in tools vs archive apps

Whether Windows 11 built-in tools or an archive app is faster depends on the task. In the July 29, 2026 rerun, Karuzip’s bundled engine compressed 1,000 files into ZIP in about one twelfth of PowerShell’s time, while Windows tar extracted that ZIP faster and built-in routes compressed one 1 GB file faster.

• Compress 1,000 files into ZIP: Karuzip 1.29 s, PowerShell Compress-Archive 15.23 s.
• Extract the same ZIP: Windows tar 0.97 s, Karuzip 1.88 s.
• Compress one 1 GB file: the bundled engine took 72.76 s, the slowest of the four methods, and produced a 142.4 MB ZIP versus 171.0 MB from tar.

Medians of five runs on July 29, 2026, using the Karuzip v1.3.0 bundled 7-Zip 25.01 engine. We have not rerun this comparison on the current release.

Updated September 12, 2026 · Written by the Karuzip team, which also ran the measurements · Test dates and screenshot versions are stated separately.

This page is for people who want numbers, not folklore. We measured Windows 11 built-in ZIP paths and archive-app workflows on the same machine, with the same datasets, and we kept the negative results visible instead of polishing them away.

Scope: this page compares Windows 11 built-in routes such as PowerShell, tar, and Shell.Application against Karuzip and the same bundled 7-Zip engine. If you want an archive-app-only comparison, use the archive extractor benchmark instead. Do not mix the seconds across those two pages because the datasets are different.

Test environment and method

• Machine: AMD Ryzen 9 5950X, 32 GB RAM, NVMe SSD, Windows 11 Pro build 26200.
• Initial run: Karuzip v1.0.3 bundled 7-Zip 25.01, PowerShell Compress-Archive and Expand-Archive, Windows tar, and Shell.Application API on July 3, 2026.
• Rerun: Karuzip v1.3.0 plus the same engine family on July 29, 2026, with five runs per scenario and the median recorded.
• Karuzip GUI-path boundary: v1.3.0 can use its built-in parallel deflate only for one unencrypted, not-already-compressed file from 16 MiB to 4 GiB at the automatic compression level. The tested v1.3.0 release had no public command-line entry point for that GUI path. The current direct-download edition includes a CLI, but these historical measurements are not current CLI timings. The reproducible Scenario 3 Karuzip row therefore measures the bundled 7-Zip engine, not the v1.3.0 GUI path; a reproducible GUI-path timing is still unpublished.
• Dataset A: 1,000 UTF-8 text files, each about 150 to 250 KB, total 389,427,154 bytes.
• Dataset B: one CSV-like file, 1,073,786,899 bytes.
• Important limit: the Shell.Application path is a completion-detection approximation because the API is asynchronous and does not return a clean finished state.
• Reproducibility: the data-generation scripts, timing scripts, and raw rerun values are published in karuzip-bench.

Rerun on 2026-07-29 (n=5)

The rerun kept the same machine but regenerated the datasets from the public scripts. The file counts and byte totals stayed the same, while the file contents changed, so compression ratios changed too. Read each table internally, not as a direct before-and-after delta versus the first run.

Scenario 1: compress 1,000 files into ZIP

For many small files, the bundled 7-Zip engine remained the fastest path. Karuzip and standalone 7-Zip were effectively tied because they are the same engine family in this scenario.

Scenario 2: extract the same 1,000-file ZIP

Windows tar stayed the fastest extractor. Karuzip remained fast enough for normal use, but not the absolute winner.

Scenario 3: compress and extract one 1 GB file

The negative result matters here: the bundled 7-Zip engine was the slowest option on a single large file. The tradeoff was a smaller ZIP, roughly 17% smaller than the Windows built-in outputs. This row must not be presented as a timing of Karuzip v1.3.0's GUI-only parallel-deflate path; that path remains unmeasured in a reproducible script.

The extraction side stayed short for every path, but Windows tar still won.

Rerun reference: 7z output

On the rerun's 1,000-file dataset, Karuzip's bundled 7-Zip path produced a 49.5 MB 7z archive in 20.47 s. That was smaller than the rerun ZIP result of 59.4 MB, with a clear time-versus-size tradeoff.

Scenario 4: AES-256 encrypted ZIP

That result matched the first run. The benchmark is specifically about AES-encrypted ZIP files, not every password-protected ZIP ever created.

Initial run on 2026-07-03

The initial run stays visible because removing older numbers would hide the actual history. These values came from Karuzip v1.0.3 and the then-current Windows-built-in routes.

Scenario 1: compress 1,000 files into ZIP

Scenario 2: extract the same 1,000-file ZIP

Scenario 3: compress and extract one 1 GB file

Initial-run reference: 7z output

When ZIP was not required, the same 1,000-file dataset compressed to 52.0 MB in 7z format, but the median time rose to 50.1 s. The benchmark is a reminder that smaller and faster are often different goals.

What the benchmark actually supports

Official references

• karuzip-bench on GitHub
• Microsoft PowerShell: Compress-Archive
• Microsoft PowerShell: Expand-Archive
• 7-Zip 25.01 release

Frequently asked questions

Related guides

karuzip-cli --json archive.compress --input ".\sample-data" --output ".\result-normal.zip" --format zip --profile normal
karuzip-cli --json archive.test --archive ".\result-normal.zip"