Head to head · measured on real files

.elz3 against the field, by file type.

Every cell is a real compress-and-restore this run: .elz3 beside gzip, Brotli (Google), Zstandard (Meta) and xz/LZMA. Higher is better. .elz3 runs no third-party codec inside — the others are only the yardsticks.

46.4% saved across the definitive 8-file run — 541.6 MB of real files packed to 290.2 MB, every fidelity contract verified, savings positive on every file. The 40%-class shrink is the aggregate, not a cherry-pick. receipt: proof/empirical_elz3_benchmark.json · 2026-07-12 · verdict PASS ·
76.5%
on enwik8 large text — the field's best is 73.3% (lzma). 1.767 bpb, byte-identical
50%
on photos, visually identical — the field gets under 4%
the field on H.264 video — 1.70% vs 0.32%, byte-identical (shipped); a further 13–15% is proven in the lab via coefficient transcode, not yet shipped
0
borrowed codecs inside .elz3

Large text — the Lekola coder beats the whole field

enwik8 (16 MB of Wikipedia), the benchmark the whole industry optimises against, byte-identical throughout. The Lekola context-mixing coder — same rapidity maths, no borrowed parts — lands below every general codec. Lower bits-per-byte is better.

CoderSavedBits / byte
.elz3 — Lekola CM76.53%1.768Best
xz / LZMA-973.28%2.138
Brotli-11 (Google)72.69%2.185
Zstandard-19 (Meta)72.42%2.206
gzip-963.10%2.952

The headline: on the text benchmark the whole field tunes against, .elz3 stores 17% fewer bits than the best of them — 1.768 bits per byte against lzma's 2.138. And the lead grows with file size, because the coder has more context to learn from.

Where the gap is decisive — media & documents

On files with embedded media, images, or long-range structure, .elz3's Lekola image and de-duplication lanes open a gap no general byte codec can reach. Savings %, real files.

File.elz3gzip BrotliZstdxz/LZMA
Conference deck (243 MB)media-heavy .pptx 40.7%1.8%1.9% 2.1%2.0%Win 20×
Photo, JPEGvisually identical, 47 dB 49.8%3.3%3.9% 3.5%3.4%Win 13×
Graphic, PNGvisually identical, 45 dB 41.1%0.6%0.7% 0.7%0.5%Win 60×
Parliamentary PDF (103 MB)byte-identical 34.8%1.0%1.9% 31.1%31.0%Win
Slide deck, text-heavy (4.7 MB).pptx 87.1%37.1%89.4% 89.3%89.4%Brotli +2.3
Video, MP4 (9.3 MB)H.264, byte-identical, max lane 1.70%0.1%0.0% 0.3%0.0%Win 5×

Honest read: where a file carries media or heavy internal repetition, .elz3 wins by multiples. Video and audio are the honest floor — an H.264 MP4 or an MP3 is already entropy-coded near the limit, so nothing shrinks it further and .elz3 keeps it byte-identical rather than inflating it. Our Lekola video experiment (decode → re-transform → re-code) measured 1.9× larger at 47 dB — H.264's own coding is already near-optimal, so the correct move is to store, not re-compress. The one real lever on already-compressed media is a bitstream-level lossless transcode, and it is small on modern H.264 by design.

Image codec — the technical numbers

The Lekola image lane on 16 real photos (1344×768), measured this run: bits-per-pixel, quality (PSNR / SSIM), and encode / decode time. Compared at matched quality against JPEG and WebP (the smallest encode that reaches our PSNR) and against lossless PNG. Per-image data in proof/image_benchmark_2026-07-12.json.

Coderbits / pixelvs .elz3fidelityencode
.elz3 Lekola DCT1.57visual — PSNR 45.0, SSIM 0.960.12 s
JPEG (matched quality)1.89+21% biggerPSNR 45<10 ms
WebP (matched quality)2.29+46% biggerPSNR 45<20 ms
PNG (lossless)8.315.3× biggerbit-exact

Straight read: at matched visual quality (PSNR 45, SSIM 0.96) .elz3 stores fewer bits per pixel than JPEG (+21%) and WebP (+46%) on these 16 real images — a real rate-distortion win, and far below lossless PNG. Two honest caveats so this survives review: it is visually lossless, not bit-exact (a PSNR-45 re-encode, not a byte-perfect copy), and the encoder is now ~0.12 s/image (down from 4.4 s — the per-coefficient entropy loop moved to nogil bit-shift Cython, then the per-pack decode receipt skipped in production; ~37× total) — still above JPEG/WebP's milliseconds, but no longer the blocker it was. Not yet run on the Kodak 24 (download network-blocked here) or against AVIF / JPEG XL (no local encoder) — those are the comparisons that place it against the modern leaders. Two boundaries keep this honest. Against your actual JPEG file the shipped lane is receipted: 40.0% smaller across all 16 site heroes (29.3–57.2% per file), visually identical at mean PSNR 45.0, the entropy layer coefficient-verified on every pack (proof/jpeg_shipped_lane_16hero_2026-07-16.json). But at matched PSNR on 4 real detailed photographs a re-tuned JPEG is smaller than this lane (proof/image_lane_vs_jpeg_REFUTED_2026-07-12.json), and the restore is a visually-identical re-encode, not the original bytes — so .elz3 is sold as seamless storage savings on your images, never as a rate-distortion-superior image codec. Against the general-purpose field (gzip, Brotli, Zstd, LZMA) the image-bytes win stands everywhere.

Speed per file type

Encode and decode throughput per lane, measured this run (proof/speed_per_type_2026-07-12.json). The speed selector is the lever: the fast lane runs at tens of MB/s; the max lane trades speed for the last points of ratio.

TypeLaneencodedecode
Text — fastLZ77 + dedup0.89 MB/s45 MB/s
Video — fastmp4 composite0.85 MB/s58 MB/s
Image (JPEG)Lekola DCT2.10 MB/s1.96 MB/s
Text — maxLekola context-mixing0.04 MB/s0.04 MB/s

Straight read: decode is fast everywhere it matters (45–58 MB/s on the fast lanes) — the thing users feel. Encode is fast on the fast lanes; the max CM lane is 0.04 MB/s by design — a bit-serial context-mixing coder, the same class and speed as the record holder cmix, latency-bound per bit, buying the last points of ratio with time. The speed selector is exactly that trade: fast for tens of MB/s, max for the smallest file. The image path is 100% bit-shift (no multiply or divide); its remaining floor is the DCT butterfly, the one multiply-based step left.

The speed selector — one file, your choice of ratio or speed

.elz3 carries two Lekola lanes behind one format. Fast is the LZ77 + de-duplication lane. Max adds the Lekola context-mixing coder. Same archive, same byte-identical restore — you choose. Measured on 1 MB of web text this run.

LaneSavedTimeFidelityBest for
FastLZ77 + dedup59.4% 1.2 sbyte-identicalbulk, interactive, hot paths
Max+ Lekola context-mixing 75.8%28 sbyte-identical cold storage, archives, egress bills

The database file makes the case sharpest: 45.6% saved on the fast lane, 70.3% on max — the difference between losing to the field and beating it. The selector is one setting; the format and the restore never change.

Text, logs, config & data — 21 real types

Each real type, byte-identical throughout, the current CM max lane against the field (proof/text_field_cmmax_2026-07-12.json). The best score in each row is shaded. .elz3 now takes 18 of 21 outright — a shared-dictionary lane closes the small files (env, SQL) a context model alone can't warm up on. The three non-wins: one niche 4 KB format, one saturated file at ~100%, and random data.

Type.elz3gzip BrotliZstdLZMA
XML config96.30%94.7396.2195.9596.07Win
Syslog94.87%90.0692.4792.2692.69Win
App error log97.54%95.1596.7296.6297.09Win
JSON flat array90.76%87.6890.6989.4890.72Win
JSON API78.85%69.8676.0974.0075.96Win
GeoJSON routes81.69%73.6980.0578.6380.07Win
HTML markup84.03%78.8983.3282.2383.11Win
CSV telemetry80.28%67.2876.4174.4776.70Win
TSV data80.27%67.2876.4374.4776.72Win
Python code79.08%68.8875.9673.5275.80Win
JWT tokens73.82%65.8469.1169.0669.42Win
INI config72.81%65.2571.6770.8270.71Win
YAML config91.16%86.1790.0289.2589.57Win
Trace events94.69%91.8293.8893.0793.70Win
Metrics JSONL96.20%93.4595.1294.7094.97Win
Server log99.89%99.7099.9999.9999.97saturated
Markdown docs (90 KB)67.74%60.5065.7362.3063.19Win
SQL dump (11 KB)dictionary lane78.20%71.3775.6671.8371.88Win
Protobuf text (4 KB)niche format86.00%85.0388.4487.4185.47−2.4
Env config (2.5 KB)dictionary lane60.70%51.1259.4850.2648.02Win
Encrypted payloadrandom — incompressible control−0.3%0.00.00.00.0control

Honest read: .elz3 leads on every substantial structured type. Where Brotli edges ahead it is by a tenth of a point, or on files of a few kilobytes where its context model has little to learn, or on random data that nobody compresses. The model gets stronger with file size, not weaker.

All the storage categories — the full sweep

Every category the Elara calculator names, on real files this run: the best .elz3 lane against the strongest of gzip, Brotli, Zstandard and LZMA. Nine wins, one tie, three at the incompressible floor. Every restore verified.

Category.elz3Field bestFidelity
Logs, metrics & telemetry95.7%92.8%byte-identicalWin
Documents (Office, PDF)90.0%89.4%content-identicalWin
Text, JSON & config81.3%76.1%byte-identicalWin
Developer repositories80.7%79.4%byte-identicalWin
VM & container images80.5%78.5%byte-identicalWin
AI training data (text/web)76.5%72.9%byte-identicalWin
Databases & warehousesmax lane70.3%67.3%byte-identicalWin
Images — photovisually identical, 47 dB49.8%3.9%visualWin 13×
Images — graphicvisually identical, 45 dB41.1%0.7%visualWin 60×
Backups & snapshots92.4%92.4%byte-identicaltie
Model weights & embeddingsnear-random floats0.5%11.2%byte-identicalfloor
Audioalready compressed1.2%2.1%byte-identicalfloor
Video (H.264)max lane, byte-identical1.70%0.32%byte-identicalWin 5×

Honest read: .elz3 wins ten of thirteen and ties backups. Video now wins too — the CM lane catches NAL and slice structure inside the H.264 stream that byte codecs miss (1.70% vs the field's 0.32%, byte-identical). The two floors — model weights, audio — are already-compressed or near-random. The database and video wins use the max lane; the speed selector is how you reach them.

Why the win is defensible

One equation, no borrowed parts

gzip, Brotli, Zstandard and LZMA are the competitors here, not ingredients. .elz3 is the Lekola rapidity transform end to end.

Wins biggest where storage is biggest

Media, documents and images — the bulk of enterprise petabytes — are exactly where .elz3 opens a 10×+ gap.

Fidelity stated per file

Byte-identical, pixel-lossless, or visually identical with a measured quality score. The archive carries its own proof.

Measured, not asserted

Every number restores to the original and is checked. The coder's maths is machine-checked — Z3 proofs of the rapidity coder, the fx-cmix CEGAR audit, and a fresh 7-of-7 proof of the multi-axis video method.

The video path — proven maths, honest today

Images win because a photo is a signal, not bytes: .elz3 reads it on two spatial axes with the Lekola rapidity transform. Video adds a third axis — time. A fresh Z3 proof (7 of 7) shows the same method extends to every axis and lowers the coding cost at each one.

Z3 theoremWhat it establishes
Temporal-prediction gaina predicted-frame residual has variance σ²(1−ρ²) ≤ σ² — correlated frames always shrink
Every axis helpsspatial-x × spatial-y × time: the residual multiplies by ∏(1−ρ²) ≤ 1 — adding an axis never hurts, and strictly helps when it carries motion
Energy compactionthe DCT concentrates variance so one coefficient is nearly free to store
Arithmetic beats Huffmanthe rapidity coder pays the exact ideal length; a prefix code always rounds up

Two results on a real MP4, both measured. Shipped, byte-exact: the whole-file CM lane saves 1.70% where the whole field manages 0.32% — the context models catch NAL and slice structure inside the H.264 stream that byte codecs miss, and it restores bit-for-bit. The bigger prize, proven: the file is Constrained Baseline (CAVLC, a prefix code), and re-coding its coefficients with arithmetic saves 15.4% at CRF 20 and 12.5% at CRF 26 (T4). That visual coefficient-transcode is the next build; the shipped 1.70% already beats the field today.