“WebP is 30% smaller than JPEG.” “AVIF is smaller still.” You see these numbers everywhere, and almost all of them come from comparisons that never matched image quality. Quality 80 in JPEG and quality 80 in WebP do not mean the same thing.
So I measured it properly. I took six images actually published on this blog — four photographs, one screenshot, and one flat illustration — and encoded each format down to the same measured quality (SSIM 0.98) before comparing file sizes.
The result: for photographs, WebP saves only 13–24% over JPEG, not 30%. For screenshots, it saves 64%. The popular figure is too generous in one case and far too modest in the other.
Sponsored
How the measurement was done
Six images published on this blog were resized to 1920px on the long edge, encoded in three formats, and measured for both file size and perceptual quality.
▼Test setup
▶ Encoder: Pillow 12.3.0 (JPEG with optimize and progressive on, WebP at method 6, AVIF at defaults)
▶ Preprocessing: Lanczos resize to 1920px on the long edge, the size actually used in blog posts
▶ Quality metric: SSIM with an 11×11 Gaussian window, sigma 1.5, computed on the grayscale channel
▶ Reference: the uncompressed resized image
SSIM returns 1.000 for a perfect match. Above roughly 0.98, differences become hard to see at 100% zoom, so 0.98 is used here as the threshold for “visually equivalent.”
The six test images
| Image | Type | Resized to |
|---|---|---|
| Close-up of a bowl of soki soba | Photograph | 1920×1440 |
| Restaurant interior | Photograph | 1920×1440 |
| Product shot of a font sample | Photograph | 1920×1440 |
| Four technical books on a desk | Photograph | 1920×1281 |
| Game screenshot | UI, heavy text | 1920×1251 |
| Flat illustrated OGP image | Large flat colour areas | 1200×676 |
Mixing in a screenshot and an illustration matters. These two behave nothing like photographs, and most format comparisons never test them.
Result 1: at quality 80, the formats are not equal
Encoded at quality 80, SSIM ranged from 0.962 to 0.997. The quality number is not portable across formats.
| Image | JPEG | WebP | AVIF |
|---|---|---|---|
| Soki soba close-up | 404KB / 0.971 | 261KB / 0.964 | 411KB / 0.985 |
| Restaurant interior | 319KB / 0.980 | 179KB / 0.971 | 294KB / 0.988 |
| Product shot | 221KB / 0.972 | 129KB / 0.962 | 242KB / 0.986 |
| Books | 236KB / 0.984 | 126KB / 0.980 | 189KB / 0.990 |
| Screenshot | 173KB / 0.988 | 101KB / 0.997 | 120KB / 0.999 |
| OGP illustration | 63KB / 0.991 | 30KB / 0.987 | 44KB / 0.994 |
Each cell shows file size / SSIM.
Two things stand out.
▼What quality 80 actually shows
① WebP at q80 is smaller than JPEG at q80, but also lower quality. SSIM fell below JPEG on all four photographs
② AVIF at q80 produced a larger file than JPEG on the soki soba photo (411KB against 404KB), yet scored 0.985 against 0.971
So part of “my files got 30% smaller when I switched to WebP” is simply lost image quality. And if AVIF ever produced a bigger file than you expected, it is because quality 80 in AVIF sits much higher on the quality scale than quality 80 in JPEG.
Comparing formats at a shared quality number is meaningless.
Sponsored
Result 2: matching quality changes the answer
At the lowest quality setting that still reaches SSIM 0.98, WebP saves 13–24% on photographs and AVIF saves 37–41%.
A binary search found the minimum quality value reaching SSIM 0.98 for each format and image.
| Image | JPEG | WebP | AVIF |
|---|---|---|---|
| Soki soba close-up | q88 / 540KB | q89 / 413KB | q74 / 337KB |
| Restaurant interior | q80 / 319KB | q88 / 267KB | q67 / 200KB |
| Product shot | q88 / 313KB | q91 / 273KB | q72 / 185KB |
| Books | q73 / 199KB | q81 / 132KB | q49 / 70KB |
| Screenshot | q71 / 149KB | q22 / 53KB | q22 / 37KB |
| OGP illustration | q46 / 35KB | q52 / 19KB | q34 / 12KB |
As savings against JPEG:
| Image | WebP | AVIF |
|---|---|---|
| Soki soba close-up | −24% | −38% |
| Restaurant interior | −16% | −37% |
| Product shot | −13% | −41% |
| Books | −34% | −65% |
| Screenshot | −64% | −75% |
| OGP illustration | −46% | −66% |
On photographs alone, WebP saves 13–24%. The more fine detail an image carries — food texture, woven fabric — the smaller WebP’s advantage becomes.
AVIF, by contrast, saved 37–41% on every photograph. The generational gap between the two codecs is real.
Result 3: screenshots are a different world
For images built from flat colour and text, WebP comes in at under a third of JPEG’s size at the same measured quality.
Look at the screenshot row again. JPEG needs q71 and 149KB to reach SSIM 0.98. WebP reaches it at q22 and 53KB — a 64% saving at identical quality.
▼Why the gap is so large
▶ JPEG works on 8×8 blocks of discrete cosine transform, which handles sharp edges badly. Text picks up ringing artefacts
▶ WebP and AVIF use intra-block prediction, which represents flat regions and repeated patterns efficiently
▶ That advantage shrinks on random texture, which is why photographs show a smaller gap
This has a direct practical consequence. If a technical blog is serving screenshots as JPEG, converting them to WebP cuts the file size to roughly a third and removes the fuzzy text at the same time. That is a far bigger win than converting photographs.
And the reverse holds: if WebP did not shrink your files as much as promised, it is because your images are photographs. That is the expected result, not a mistake.
Sponsored
So which format should a blog use?
WebP is the right default in 2026. AVIF is worth reaching for only on unusually large single images.
The raw numbers favour AVIF, but two practical constraints push against it.
| Consideration | JPEG | WebP | AVIF |
|---|---|---|---|
| Size at matched quality (photos) | baseline | −13 to −24% | −37 to −41% |
| Size at matched quality (UI, art) | baseline | −46 to −64% | −66 to −75% |
| Browser display support | universal | universal | near universal |
| Encoding in the browser | yes | yes | no |
| Encoding speed | fast | slower | much slower |
The first constraint is how you produce the file. A browser canvas can only export JPEG, PNG and WebP through toBlob(); major browsers do not support image/avif as an output type. Any converter that runs entirely in the browser is bound by this.
The second is encoding time. AVIF took tens of times longer than JPEG in this test. Encoding six images across every quality step took over twenty minutes in total. For batch conversion of dozens of files, that difference is felt immediately.
▼Recommendations by use
① Photographs in post bodies: WebP. Good balance of size and compatibility
② Screenshots and diagrams: WebP without question. Around a third of JPEG’s size, and text stays crisp
③ One very large hero image: AVIF is worth considering
④ Diagrams still sitting as PNG: convert them first. The OGP image here went from 629KB to 19KB
Point four is the one most people miss. Plenty of blogs upload screenshots as PNG and leave them there. The 629KB PNG in this test became a 19KB WebP — a factor of 33.
Converting without uploading anything
Trying this yourself needs a converter. This blog publishes a free batch image converter.
▼What it does
▶ Converts between JPG, PNG and WebP, processes multiple files at once, and returns a ZIP
▶ Quality (1–100) and a maximum long-edge dimension are both adjustable
▶ Images are never uploaded to a server. Everything runs inside the browser
▶ AVIF output is not available, for the reason described above
The no-upload behaviour matters for work material and unpublished photographs. Most online compression services send your file to a server, process it there, and send it back.
The default preset is WebP at quality 80 with a 1920px long edge. Based on this measurement, that is a reasonable setting for photographs but heavily excessive for screenshots. Drop the quality substantially when converting UI images.
Related reading
▶ What quality setting should you use for images? — the follow-up measurement, once the format is decided
▶ Handling WebP files comfortably on a Mac — opening and converting WebP on macOS
▶ Building an image compression GUI in Python — the same job as a desktop tool
Summary
Comparing formats at the same quality number tells you nothing. Quality 80 describes a different picture in JPEG, WebP and AVIF.
With quality matched at SSIM 0.98, the measured results were:
▼What the numbers showed
① Photographs: WebP saves 13–24% over JPEG. “30% smaller” overstates it
② Photographs: AVIF saves 37–41%. The codec generation gap is genuine
③ Screenshots and illustrations: WebP saves 46–64%, AVIF 66–75%. A different order of magnitude
④ PNG diagrams: the largest win of all, 629KB down to 19KB
In practice, WebP is enough for a blog. AVIF buys another 20% at matched quality, but cannot be produced in a browser and encodes slowly. And the biggest single improvement available is not converting photographs at all — it is converting the screenshots that are still sitting there as PNG.
Measurements were produced with the Pillow 12.3.0 encoders. Different encoders such as cwebp or avifenc, or different settings, will shift the numbers. SSIM approximates perceived quality and does not perfectly match what the eye sees.
