By Dik Raci · Creator of online tools · About the author

JPEG vs WebP vs AVIF: We Ran 360 Real Encodes and Published Every Number

Ask five developers which image format saves the most space and you will get five confident, contradictory answers. Somebody swears by AVIF, somebody says WebP is smaller, somebody ships JPEG at quality 80 because a blog post from 2017 said so. Almost nobody has the actual numbers for their own content. We got tired of the folklore, so we ran a controlled bake-off: 12 test frames at 1920 pixels wide, encoded at ten quality levels in three formats - 360 real encodes in total - and we wrote down every file size. This article publishes all of it, plus fidelity measurements (PSNR) and encoding timings, so you can see exactly where each format wins and where it quietly loses.

How we tested, so you can reproduce it

Every encoder takes shortcuts on some content and shines on others, which is why single-image comparisons are useless. We built a deterministic set of 12 test frames that exercise the features real photographs actually use: sky gradients, terrain with organic silhouettes, geometric structures, and calibrated film grain, at 1920 × 1080 pixels. The frames are generated programmatically, which means anyone can regenerate the identical set and check our numbers - no stock-photo licensing, no cherry-picking.

All encodes ran on August 31, 2026 with Pillow 11.3: JPEG through libjpeg with optimize and progressive enabled, WebP through libwebp at method 6 (maximum effort), and AVIF through libavif at speed 6. We recorded the exact byte size of every file, then computed PSNR against the untouched originals on a three-frame subsample. One honest caveat before the tables: because our frames lean on smooth gradients, lossy formats with strong prediction (WebP and AVIF) look even better here than they might on dense foliage or razor-edged text. Treat the shape of the curves as the finding, and always re-measure on a sample of your own images before committing a migration.

The complete results: median size at every quality level

Finding 1: AVIF owns the low-quality range - by an absurd margin

At quality 50, AVIF files were 95% smaller than JPEG: a median of 2 KB against 37 KB. Even WebP, the previous efficiency champion, needed four to five times more space than AVIF in the 50-65 range. If your use case genuinely tolerates aggressive lossy compression - thumbnails, preview grids, lazy-loaded placeholders, chat attachments - AVIF at quality 50-60 produced files measured in single-digit kilobytes that still hold a PSNR above 40 dB on our frames. Nothing else came close, and this is consistent with what AVIF's AV1-based prediction is known for: it spends bits on structure rather than pixels.

Finding 2: a quality number is not a quality level across formats

The single most useful thing this table teaches is that quality settings are not comparable between encoders. Quality 80 produced a 126 KB JPEG, a 27 KB WebP, and a 113 KB AVIF - three completely different files that carry three different amounts of fidelity. If a migration script converts your JPEGs to WebP at the same numeric quality, you are silently shipping much lower fidelity per image. The reverse is true going from JPEG to AVIF at high settings. Any format migration needs to target an outcome - a byte budget or a measured PSNR floor - not a magic number carried over from a different encoder.

Finding 3: AVIF inverts above quality 85 and becomes the largest file

This is the result we did not expect. From quality 85 upward, AVIF median sizes blew past both veterans: 247 KB at q85 (JPEG: 170 KB), 389 KB at q90, and 577 KB at q95 - 23% larger than JPEG at the top setting. The reason is structural: AV1's quantizer mapping is tuned to allocate aggressively at low bitrates, and at high quality targets on smooth content it starts spending bits generously without a proportional fidelity gain. The practical takeaway is uncomfortable but clear: AVIF at maximum quality is usually a waste of bytes. If you need near-transparent fidelity, JPEG or WebP at 90+ were cheaper in this test.

Finding 4: fidelity per kilobyte tells a fairer story

Raw size comparisons ignore what you get for the bytes, so we measured PSNR against the originals on a three-frame subsample. At quality 80, WebP delivered 40.35 dB at a median of 27 KB while JPEG needed 126 KB to reach 41.41 dB - roughly similar perceptual territory at a fifth of the size. AVIF at the same setting hit 42.42 dB at 113 KB, the highest fidelity of the trio at that point on our frames. Below 30 dB images look visibly degraded and above roughly 43-45 dB differences are imperceptible on ordinary content, so all three formats were operating in the acceptable band at quality 80 - they just take very different paths to get there.

Finding 5: encoding speed is part of the price

Compression is not free - someone's CPU pays for it, either your build server or your visitor's browser. Encoding all 12 frames at quality 80 took 0.24 seconds for JPEG (about 20 ms per image), 2.2 seconds for WebP method 6 (about 183 ms per image), and 4.09 seconds for AVIF speed 6 (about 341 ms per image). PNG with full optimization was the slowest of all at over 1.7 seconds per image. On a one-off build this is irrelevant. On a user-generated-content pipeline compressing thousands of uploads per hour, a 17x encode-time difference between JPEG and AVIF is an infrastructure decision, not a detail.

What we would ship, based on these numbers

• Hero images and portfolio shots: WebP at 85-90 or JPEG at 85-90 - the high-quality ranges where both stay cheaper than AVIF while holding 41+ dB.
• Content images in articles: WebP at 75-80 hit the sweet spot in our data: ~15-27 KB medians at 40 dB, which is a 5x saving over the equivalent JPEG.
• Thumbnails and previews: AVIF at 50-60 produced 2-6 KB files - nothing else was even in the same country.
• Automated pipelines: JPEG at 80 remains the speed king; use WebP/AVIF where the byte savings justify 9-17x more CPU.
• Never migrate by copying quality numbers between formats - target a byte budget or a measured fidelity floor instead.

Limitations of this test

Three limits bound what you should conclude here. First, our frames favor smooth-gradient prediction, which flatters WebP and AVIF; noisy, high-detail photography will narrow their lead. Second, we tested one encoder build - libvpx-derived libwebp and libavif at one speed setting - while browsers and build tools ship different versions with different tuning. Third, PSNR is a coarse fidelity metric; it rewards the smooth, blur-tolerant behavior of AV1-family encoders. The replication advice stands: pull 20 of your own images, run them through our exact settings, and compare medians before you commit. The tooling to do that in a browser is exactly why our image converter and compressor exist.