Archive extractor benchmark: Karuzip, 7-Zip, WinRAR, and Lhaplus

In the July 29, 2026 rerun, no app was faster in all three tests. Karuzip’s bundled engine compressed 1,000 files into ZIP faster than WinRAR, while WinRAR extracted that ZIP faster and compressed one text-heavy file into ZIP faster than the bundled engine.

• Compress 1,000 files into ZIP: Karuzip’s bundled engine 2.50 s, WinRAR 4.14 s.
• Extract the same ZIP: WinRAR 2.25 s, Karuzip 2.91 s.
• Compress one text-heavy file into ZIP: WinRAR 1.44 s, the bundled engine 14.79 s. This test excludes Karuzip’s native GUI compression path.

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 October 9, 2026 · Written by the Karuzip team, which also ran the measurements · Test dates and screenshot versions are stated separately.

This page answers the narrower question: once you already know you want an archive app, which one fits the measured tradeoffs best? We kept Karuzip, 7-Zip, WinRAR, and Lhaplus in the same frame and left the awkward results visible.

Test environment and method

• Machine: AMD Ryzen 9 5950X, 32 GB RAM, NVMe SSD, Windows 11 Pro build 26200.
• Initial run on 2026-07-10: Karuzip v1.0.3 bundled 7-Zip 25.01, WinRAR 7.23, and Lhaplus 1.7.4 under default settings.
• Rerun on 2026-07-29: Karuzip v1.3.0, standalone 7-Zip 25.01, and WinRAR 7.23 with five-run medians.
• Karuzip GUI-path boundary: v1.3.0's parallel deflate is a GUI-only path for one unencrypted, not-already-compressed 16 MiB–4 GiB file at the automatic level. Because the published scripts cannot invoke it, the Scenario 3 Karuzip rows measure the bundled 7-Zip engine. Reproducible GUI-path timing remains unpublished.
• Dataset A: 1,000 files totaling 378,880,000 bytes, each about 370 KB and deliberately harder to compress than the dataset used on the Windows-built-in benchmark page.
• Dataset B: one text-heavy file totaling 209,717,377 bytes.
• Lhaplus note: it was not timed in the rerun because it has no reproducible command-line path for scripted timing. Its support limits were still tested and reported.
• Reproducibility: the raw rerun measurements and scripts are published in karuzip-bench.

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

The rerun regenerated the datasets from the public scripts, so the byte totals stayed the same while the contents changed. Read the rerun tables on their own terms instead of treating them as a direct delta from the initial run.

Scenario 1: compress 1,000 files into ZIP

Karuzip and 7-Zip were effectively tied because they are the same engine family here. WinRAR was slower and produced a larger ZIP in this many-file scenario.

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

This is one of the negative results that should stay visible: WinRAR extracted the rerun ZIP faster than Karuzip in this scenario, although the absolute difference was still well under one second.

Scenario 3: compress one text-heavy file

WinRAR won the reproducible rerun single-file ZIP speed test by a large margin against Karuzip's bundled 7-Zip engine path. The table does not measure the v1.3.0 GUI-only parallel-deflate path, whose reproducible timing remains pending. The bundled engine won only if the target was the smaller 7z output, which took much longer to produce.

Initial run on 2026-07-10

The initial run is kept as a record of the first measurement, but read it with two limits. Its raw data was not published. And five of its timings — both rows in Scenario 2 and the first three rows in Scenario 3 — were recorded as exactly 2.01 s even though they are different operations. Identical values like that point to a timing problem rather than a real tie, so do not use those five timings for comparison. Use the n=5 rerun above instead.

Scenario 1: compress 1,000 files into ZIP

Scenario 2: extract the same ZIP

Scenario 3: compress one text-heavy file

Only the output sizes in this table are usable. The timings cannot say which tool was faster, and the dataset was regenerated for the rerun, so the two runs should not be read as a before-and-after comparison.

Lhaplus limits that still matter

The benchmark does not argue that Lhaplus instantly breaks in every case. It does show that newer archive habits, especially large files and 7z, leave it with hard practical limits.

Feature and support matrix

What this benchmark actually supports

• Choose Karuzip or 7-Zip for many-file ZIP and 7z workflows. The measured core engine is effectively the same there, so the choice turns into interface, update path, and workflow preference.
• Choose WinRAR if RAR creation is mandatory. It also won the rerun single-file ZIP speed test and the rerun extraction test.
• Do not use Lhaplus as the default recommendation for new users. The measured 4 GB failure and limited 7z support (provisional extraction only, no creation) are practical blockers, not cosmetic ones.
• Do not oversimplify the dataset story. The rerun narrowed or reversed some gaps, so the honest answer depends on the type of archive work.

Official references

• karuzip-bench on GitHub
• 7-Zip 25.01 release
• WinRAR official site
• Lhaplus official site

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"