Save photos for the web as WebP. On our six test images WebP matched JPG’s measured quality in 71–86% of the bytes on photos and 27–45% on screenshots and a logo, and it took well under a second per image. AVIF went further, to about half of JPG on photos, at five to nine times JPG’s saving time. We’d spend that time on the one or two largest images of a page and nowhere else. JPG keeps its place for files that leave the web.
How we measured
On 23 September 2026 we ran six images through the same encoders our free tools use: MozJPEG for JPG, libwebp for WebP, libavif for AVIF and OxiPNG for PNG. The run used Chromium 153 (headless) on an Apple M5 Max laptop, and a second pass through the real tool pages gave byte-identical files. The set: a 2816×1536 photo, a 922×1152 portrait, a 1408×768 photo saved as PNG, a 1440×900 app screenshot, a 1200×1600 screenshot of a page of text, and a 960×300 logo on a transparent background. “Same quality” means the same SSIM, computed on the full-resolution brightness channel in 8×8 pixel windows placed every 4 pixels, then averaged (1.0 is identical). For each WebP and AVIF file we found the JPG size that would score the same, interpolating between the two JPG settings either side of it among 60, 75, 85 and 95. Where no JPG setting in that range bracketed it, the cell says so instead of guessing.
We started somewhere else. The tools show a quicker similarity score on screen. It works on a 128-pixel-wide preview and rated every lossy file between 0.9985 and 0.99999, which is fine for “looks the same” and useless for ranking formats: it put JPG 60 above WebP 95 on the large photo. None of the numbers below use it.
WebP and AVIF against JPG, byte for byte
| Image | WebP 60 | WebP 75 | WebP 85 | AVIF 50 | AVIF 60 | AVIF 75 |
|---|---|---|---|---|---|---|
| Photo, 2816×1536 | 85% | 86% | 78% | no match | no match | 53% |
| Portrait, 922×1152 | no match | 71% | 76% | no match | no match | 43% |
| Photo saved as PNG | 73% | 76% | 74% | no match | no match | 48% |
| App screenshot | 42% | 30% | no match | 38% | 30% | 25% |
| Text page screenshot | 27% | no match | no match | 33% | 28% | 26% |
| Logo, transparent | 40% | 42% | 45% | 27% | 26% | 24% |
On the three photos WebP needed 71–86% of JPG’s bytes, median 76% across eight matched pairs. Google’s WebP page says lossy WebP files are “25-34% smaller than comparable JPEG images at equivalent SSIM quality index”, which would put WebP at 66–75%. Our photos saved less than that, 14 to 29%. The likeliest reason is the opponent. Google’s study encoded its JPGs with libjpeg 6b and the -optimize flag; we used MozJPEG, which adds trellis quantization and tuned progressive scans. We think that stronger JPG accounts for most of the gap, but we haven’t run libjpeg 6b on these files to prove it. On the screenshots and the logo the gap runs the other way and is far larger than Google’s figure. WebP needed 27–45% of JPG’s bytes, because JPG handles hard edges badly.
On the text page JPG never caught up: at 95 it scored 0.9969, just under WebP at 75 (0.9972), and weighed 342 KB to WebP’s 98 KB.
AVIF at slider 75 needed 43–53% of JPG’s bytes on photos. web.dev’s AVIF article reports “greater than 50% savings vs. JPEG”, and our three photos land either side of that line, so we have no quarrel with it. At the lower AVIF settings every photo scored below JPG 60, too soft to match, which is why those cells say no match. On the graphics AVIF needed 24–38% of JPG’s bytes at every setting we tried.
One trap shows up in almost every “WebP vs JPG” test you’ll find: comparing the same slider number. WebP 75 was 58–83% of JPG 75’s size on our photos, but it also scored a little lower on all three (0.928 against 0.930 on the large photo). Put the two 75s side by side and WebP looks better than it is. The guide to JPG quality settings has more on why those numbers don’t line up between formats.
AVIF pays for those bytes in time.
| Image | JPG | WebP | AVIF |
|---|---|---|---|
| Photo, 2816×1536 | 282 | 543 | 2,219 |
| Portrait, 922×1152 | 61 | 102 | 496 |
| Photo saved as PNG | 71 | 115 | 634 |
| App screenshot | 63 | 87 | 335 |
| Text page screenshot | 114 | 145 | 540 |
| Logo, transparent | 15 | 328 | 106 |
WebP barely slowed things down. Apart from the logo it took 1.3 to 1.9 times JPG’s time, while AVIF took 5 to 9 times as long as JPG on every image. That was with libavif at speed 6, the setting web.dev recommends “as a balance of encode speed, compression efficiency, and quality”. Two seconds for one photo is nothing. Two seconds each for a folder of a few hundred is a coffee break, and that’s on a fast laptop; we didn’t time a phone.
The logo row is the odd one. WebP took 328 ms against 15 ms for JPG and 106 ms for AVIF, on the smallest image in the set. It is the only file with transparency, and our WebP settings keep the alpha channel at full quality with the slowest compression method, but we haven’t isolated which of those costs the time.
Support stopped being the excuse
caniuse puts WebP at 96.82% of global browser usage and AVIF at 95.36%. Full WebP support starts at Safari 16.0. For AVIF you need Safari 16.4, Firefox 93 or Edge 121, the last of the big ones to add it. Websites haven’t moved. The 2024 Web Almanac found an image is the largest thing painted on 73.3% of mobile and 83.3% of desktop pages, and among those images JPG made up 61%, PNG 26%, WebP 7% and AVIF 0.3%. Those last two were 4% and 0.1% in 2022. The PNG slice is the cheapest to fix: our PNG to WebP converter at its default 85 cut the app screenshot by 55% and the text page by 51%, with higher SSIM than a JPG at 85 would have given.
PNG, and where JPG still wins
PNG is lossless, so it belongs to files whose pixels must stay exact. Re-packing with OxiPNG, which changes no pixels, brought our screenshot, text page and logo to 74%, 69% and 72% of their original size and the photo saved as PNG to 96%. Going the other way hurts: turning our two JPG photos into PNG made them 1.92 and 1.81 times larger, with no detail gained. PNG to JPG at quality 90 cut the screenshots by just 3–4%, and any transparent area came out white, or whatever background colour you pick instead.
Our WebP default is wrong for anything that goes to a person rather than a page.
Some older desktop apps and print services still won’t open WebP, and an AVIF attachment is a worse bet again. Keep JPG originals for those, and turn stray WebP or AVIF downloads back with WebP to JPG or AVIF to JPG. For the web side, JPG to WebP does whole folders, and the compressor saves AVIF if you pick it under “Save as”.