We Measured What Image Formats Actually Cost

What we measured, and how

Five images, 800×600, each built to isolate one thing codecs handle differently. Every one is generated from a fixed seed by a script in this repository, so the corpus is reproducible and there is no licensing question hanging over it.

Each sample was encoded to JPEG, WebP and AVIF at qualities 50, 65, 75, 85, 95, plus PNG and lossless WebP. We recorded the encoded size and the mean SSIM against the original: mean SSIM, luma plane, 8×8 windows at stride 4, C1=(0.01·255)², C2=(0.03·255)².

Encoder: libvips 8.18.3 via sharp 0.35.3, on Node v22.15.0. That matters for one reason worth being upfront about — FileTools360's own converters run WebAssembly builds in your browser, not this Node pipeline. Same codecs and same settings, different host, so treat these as the shape of the answer rather than a byte-for-byte promise about the tool pages.

Measured 2026-09-12.

• Smooth gradient — Continuous tone with no detail — the easiest thing to compress, and where banding shows first.
• Hard-edged text and UI — High-contrast edges. This is where JPEG's ringing artefacts appear and where PNG wins.
• Film-like noise — Random detail. Incompressible by design — the worst case for every lossy codec.
• Flat colour blocks — Large areas of one colour — a logo or a chart. Lossless formats should crush this.
• Soft alpha edge — A transparent gradient. JPEG cannot store it at all, which is the single most common reason a conversion surprises someone.

File sizes at quality 75

Quality 75 is where most people ship, so it is the fairest single comparison. Sizes are what the encoder wrote.

Two results are worth stopping on. On hard-edged text, JPEG at quality 75 produced 74 KB — larger than the 87 KB PNG, and more than ten times the 5.8 KB lossless WebP. Lossy compression is not just worse-looking on sharp edges, it is bigger. And on flat colour, lossless WebP came in at 140 B, against 4.6 KB for JPEG.

The opposite case is noise. Random detail is incompressible, so the PNG ran to 1089 KB and the lossy encoders all landed near 164 KB. If your image is grainy, lossless is the wrong tool.

How much was actually lost

Size alone proves nothing — any encoder can be small if it is allowed to be wrong. SSIM scores structural similarity to the original, where 1.0000 is identical.

Read the alpha row with suspicion, and this is the useful lesson in the whole exercise. JPEG cannot store transparency at all, so that sample had to be flattened onto white before JPEG could touch it, and the comparison is made against the same flattened reference. SSIM therefore reports a comfortable score for an encode that silently threw away the one property the image existed to demonstrate. A metric answers the question you asked it, not the question you meant.

What raising the quality setting buys

On a smooth gradient — the easiest thing to compress — the quality slider moves the file size a long way and the visible result very little, until the top of the range where it moves the size sharply.

From q50 to q95, JPEG goes from 4.6 KB to 34 KB. The practical advice people give — stay in the 75–85 band — holds up here.

One caveat on this sample specifically: SSIM under-reports banding, which is the artefact smooth gradients actually suffer from. The numbers below are honest about size and optimistic about gradient quality.

What this does not tell you

These samples are synthetic on purpose, because each one isolates a property and therefore explains something. A photograph is a mixture of all of them, so it will land somewhere between these rows — the corpus predicts the shape of the answer, not your exact ratio.

Encoder versions matter, and every encoder here is a specific build named above. AVIF in particular has improved substantially between releases, and a different libaom or a different effort setting will move its numbers more than the others.

Nothing here measures decode speed, encode time, or browser support. AVIF was frequently the smallest and is also the slowest to encode, which is a real trade-off on a phone and is not visible in a size column.

Reproducing this

Clone the repository and run `npx tsx scripts/seo/format-benchmark.ts`. It writes `docs/seo/data/format-benchmark.json`, which is what this page reads — the tables above are that file, formatted. If your numbers differ from ours, the encoder build is the first thing to compare.

The SSIM implementation is in the same script rather than pulled from a package, so the method is inspectable next to the results.