Measured · 301 packs · one machine

What Crate saves, and how we measured it.

72.5% aggregate reduction 301 real packs Both figures computed by the engine

That aggregate is the least interesting number on this page, because one total hides every session that did badly. So the rest of this page is the spread behind it, the cohort that actually does the work, the packs at the very top of the range, a head-to-head against thirteen archiver configurations on size and on time in both directions, and the three things we are careful never to claim.

Method

Two byte counts, one subtraction.

Measured · 301 packs

The spread, not the headline.

Every quantity on this page sits on the same rule, so you can compare them by eye. Here is the reduction achieved across all 301 packs — the box spans the middle half, the line is the median, and the whisker runs from the bottom tenth out to the best result recorded.

Measured · 35 packs above 89%

What is actually up at the top of the range.

A distribution that reaches 96.0% invites one fair question: does anything real live there, or is the tail a rounding artefact on a folder of empty files? These are the packs above 89%. There are 35 of them, and 16 are sessions of 1 GB or more. This is the evidence behind the “up to” end of the claim, and it is the top of the range — not the result to expect.

Six of the 35, chosen to show the sizes involved rather than the best ratios. Every one is a multi-gigabyte session, so the tail is not an artefact of tiny folders. It is also not typical: the median for sessions of 1 GB and over is 72.6%, and across all 301 packs it is 58.6%. If you are budgeting a drive, budget with those two.

Measured · benchmark run 2026-08-20

Against every major archiver, at their best settings.

Twenty real client sessions, named by class and never by client, pooled into four lanes and packed by Crate on both shipping presets and by eleven other archiver configurations set for maximum compression — thirteen configurations on every session. Rows are ordered by engine family, not by result. Every number in the three tables below is measured; nothing in them is projected.

How the run was done. Each session was packed once per configuration, serially, one machine, nothing else running. A lane sums its member sessions — every figure below is computed on the summed bytes and summed seconds, never averaged across sessions.

Size — reduction achieved

Reading the bar colours

• Crate. Both presets, on the same rule as every other bar on this page.
• Package under 1.5× the size of ours. Bigger than Crate’s, but within half again.
• Package 1.5× the size of ours, or more. One round threshold, applied identically to all four lanes — never tuned per column.
• Did not give every byte back. The one mark on this page that is not about size. Hatching outranks any colour band.

Amber and red here mean size, and nothing else. RAR, 7-Zip, xz, zstd, gzip and ZIP all restored every class at 100% verified. A red bar says the package came out larger; it never says the engine is unsafe. Integrity has its own channel — the hatch — precisely so the two can never be read as one claim. The band is computed from the measured sizes already in the table:

Two notes on the swatches. These bars are a size scale and sit only inside the benchmark tables; the square teal and amber chips in the reading key at the top of the page are a provenance scale — measured against derived — and appear only on text. Different shape, different place, different question. Crate’s own rows take no band at all — the reference point carries the measured teal, and the bands classify only the other engines. And nothing in these three tables is derived anyway: every figure in them was measured on the run.

One consequence of a fixed threshold, stated so it is not mistaken for tuning: zstd --ultra -22 lands inside amber on the live pool and well into red on stems. Same rule, two pools, two answers.

Every lane is complete. All thirteen configurations finished on every one of the twenty sessions, so no cell in the three tables above is blank — and none of them is guessed.

Time to pack — seconds per gigabyte

Smaller usually costs time; here it did not. Crate packed faster than every other configuration in every lane. Three results from the table, plainly: on the stems pool, ZIP -9 takes 53.4× Crate Default’s pack time to land 16.1 points behind on size. On the mixed pool, 7-Zip -mx=9 solid + delta takes 36.1×. On the loop-heavy pool that same configuration spends 302.51 s/GB against Crate’s 6.41 and still finishes 12.8 points behind.

Slowest pack in each lane: 7-Zip -mx=9 solid + delta at 36.1× on the mixed pool and 47.2× on loop-heavy, ZIP -9 at 53.4× on stems, zstd --ultra -22 --long=31 at 30.1× on live. The closest anything came to Crate was FLAC + tar at 1.4× — the one configuration that lost files.

Time to open — seconds per gigabyte

The direction that matters when you are trying to get back to work. Nobody wins this one everywhere, and the table says where. Crate opens quickest on the mixed and live pools. On loop-heavy and stems it trades blows with zstd --ultra -22 --long=31: differences of hundredths of a second per gigabyte, which under our tie rule are ties rather than wins for anyone.

Read this table with one caveat, and it cuts both ways. Unpack time is a full expand of the archive to a fresh tree. It excludes Crate’s per-file SHA-256 verification pass — work no other engine performs at all. So our figures here flatter us, and everyone else’s describe an expand that never checks whether the bytes came back. FLAC + tar expanded the mixed pool at 4.45 s/GB; 25.4% of what came out matched the source.

Settings, as run

Not claimed

Three things this page does not say.

What we do claim, and gate every release on, is separate from all of this: a restored session is bit-identical to the original, per file, by SHA-256 — or the file is reported as failed and quarantined rather than delivered. Size is a benefit. Fidelity is the product.

Known bias

Where these figures are weakest.

Every dataset has a shape imposed by how it was collected. Here is the shape of this one.

• Floor

  These totals are a floor, not a census. Analytics are opt-out and not every install is on the current version, so packs exist that this dataset has never seen. The true aggregate is larger than 711.43 GB by an amount we cannot measure and will not estimate.

• One machine

  The 301 packs come from a single working machine and its real client sessions. That is a genuine workload rather than a synthetic corpus, but it is one studio’s taste in material, sample rate and plugin set — not a survey of the industry.

• Single run

  Every benchmark timing is one run on one machine, serial, with nothing else running. It is not averaged across repeats, so small gaps carry no information — treat anything under a second as a tie. The size figures do not have this problem: an archive is the size it is.

• A correction

  The xz --delta=dist=6 -9e row was measured twice. On the first run its filter never engaged: the harness placed a bare -9e preset after --delta, which resets the xz filter chain, so that archive came out byte-identical to plain xz -9e. The harness was corrected and the row re-measured on a quiet machine; the figures in all three tables above are that corrected run. It is written down here rather than quietly replaced.

• Verification

  Unpack times exclude Crate’s per-file SHA-256 pass, which no other engine performs. That flatters our restore figures, and it is also the reason a Crate restore can tell you a file came back wrong while a plain expand simply cannot.

• Corpus

  The head-to-head corpus is twenty real client sessions, grouped into four pooled lanes named by class and never by client. Pooling closes the door on cherry-picking: a lane figure includes every session in its class — there is no exemplar to pick. Twenty sessions show a consistent margin; they are not enough to promise one on material we have not seen.

• Tail

  The 35 packs above 89% are the top of the range and nothing more. They are shown because a claim that reaches 96.0% should have to produce the sessions that got there — not because they predict yours. The two numbers worth planning around are 58.6% across all packs and 72.6% for sessions of 1 GB and over.

• Settings

  Every competing archiver ran at maximum compression, with a large dictionary and solid mode where supported. If you can beat these numbers with a better configuration, we would rather know than not — the settings are listed above so the run is reproducible.

• Units

  Decimal throughout: 1 GB = 10⁹ bytes. Reading these figures as binary GiB would overstate every size on the page by about 7%.