Switching a photo from JPEG to AVIF cuts its size by a third to a half at the same visual quality — but the popular middle option, WebP, can quietly make your high-resolution photos bigger. We compressed hundreds of images to measure exactly how much space each format really saves.
📄 Download the full study as a PDF
Prefer a formatted, citable paper? This study is also available as a 5-page journal-style PDF — "Iso-Quality Storage Efficiency of JPEG, WebP, and AVIF" — with all figures, tables and references. → Download the PDF (journal format)
TL;DR
- We encoded the standard 24-image lossless Kodak test set plus 8 real 12-megapixel photos to JPEG, WebP and AVIF across eight quality levels — 768 encodes in all — and measured the size needed to reach the same measured visual quality (SSIM), using sharp/libvips to encode and ffmpeg to score.
- At matched quality, AVIF wins clearly: −52% vs JPEG at good quality (SSIM 0.95) and −36% at high quality. WebP is a steady −34% vs JPEG.
- The WebP catch: on real 12 MP photos, re-compressing to WebP made files 25–57% larger than an equal-quality JPEG. WebP only wins from a pristine original — not when re-compressing the JPEGs already on your phone.
- Real numbers: at visually identical quality, a 12 MP photo needs about 1.0 MB as AVIF versus 1.4 MB as JPEG — roughly a third smaller, format-for-format. (Versus the original ~1.6 MB JPEG on your phone, AVIF is smaller still.)
- The "quality" slider lies: quality 80 means a different size and different actual quality in each format. You can only compare formats by measured output quality, not by the number.
Why this is worth a few hundred megabytes
On almost every full phone, photos and videos are the single biggest storage consumer — usually a larger slice than apps, messages and downloads combined. That makes the format and quality your pictures are stored in the real lever for getting space back, far more than deleting a handful of apps you'll just reinstall.
The catch is that "just compress your photos" hides a lot of detail. The same picture can be saved as JPEG, WebP or AVIF, at any quality setting, producing wildly different file sizes — and, crucially, different actual visual quality even when the slider reads the same number. Pick the wrong format and you can shrink a photo with no visible benefit, keep visible quality you didn't need, or — as we found with WebP — accidentally make a photo larger than it started.
So we measured it. The question we wanted to answer in plain terms: for the same picture, viewed at the same quality, how many bytes does each format actually need? That is the number that decides whether compressing your library is worth it, and which format to use.
How much smaller is the same photo?
Using the lossless Kodak images, we found the smallest file each format needs to reach an identical visual-quality score (SSIM). At everyday "good" quality (SSIM 0.95):
| Format | Size for one photo | vs JPEG |
|---|---|---|
| JPEG | 55.5 KB | — |
| WebP | 36.5 KB | −34% |
| AVIF | 26.7 KB | −52% |
AVIF's lead is biggest at everyday quality and narrows as you push toward visually lossless:
| Visual quality (SSIM) | AVIF vs JPEG | WebP vs JPEG |
|---|---|---|
| 0.95 (good) | −52% | −34% |
| 0.98 (high) | −36% | −34% |
| 0.99 (near-lossless) | −17% | −34% |
At near-lossless quality WebP's steady −34% actually beats AVIF. But at the quality most people store photos at, AVIF saves the most.
The WebP trap: re-compressing real phone photos
Lossless test images flatter every codec. So we ran the same test on 8 real 12-megapixel photos — the kind already in your camera roll — re-compressing each to match its original quality (SSIM 0.98):
| Format | Size per 12 MP photo | vs JPEG |
|---|---|---|
| JPEG | 1.35 MB | — |
| WebP | 1.69 MB | +25% (larger) |
| AVIF | 0.96 MB | −29% |
(Sizes here are in MiB — 1,024² bytes — the same unit your phone uses to show storage. In plain decimal MB they're about 1.42, 1.78 and 1.01 MB; the percentages are identical either way.)
AVIF held its ~30% advantage over an equal-quality JPEG. But WebP made the photos bigger — 25% larger at high quality, and up to 57% larger near-lossless. Converting the JPEGs already on your phone to WebP to "save space" can backfire. AVIF was the only format that reliably shrank real photos.
Why does WebP inflate? Two things stack up. First, the source photos are already JPEG, and re-saving a JPEG as JPEG is unusually cheap because the math JPEG uses to shrink a photo is reused — so the file barely grows the second time. Second, libwebp is simply inefficient at high fidelity on large images: to hit "visually lossless" on a 12-megapixel photo it spends a lot of bytes. Put together, the JPEG you're starting from is a low bar that WebP can't beat. AVIF's encoder doesn't have this weakness, which is why it keeps winning even on real phone photos.
You can see the crossover clearly when you plot size against quality for every setting: the WebP line starts low but climbs steeply and overtakes JPEG past the high-quality mark, while AVIF stays underneath the whole way.
(One honest caveat: at the near-lossless end, several of these real JPEGs were already so close to identical that their quality scores barely moved between the top settings. That makes the exact 0.99 figures the noisiest in the study — but the direction is unmistakable, and the high-quality 0.98 result is solid.)
What it means for your storage
- AVIF saves space in every scenario — fresh exports and re-compressed phone photos alike. Format-for-format at matched quality, a 12 MP photo needs about 1.0 MB as AVIF versus ~1.4 MB as JPEG, with no visible quality loss. Compared with the original ~1.6 MB JPEG already on your phone, the saving is bigger still.
- Don't trust the quality slider. "Quality 80" produces different file sizes and different actual quality in JPEG, WebP and AVIF (see the methodology below for the exact numbers). Judge by the result, not the number.
- WebP is great for the web from clean originals, but a poor choice for re-compressing existing high-quality photos.
- HEIC (what iPhones shoot by default) is already in AVIF's league. If your newer photos are HEIC, they're roughly as efficient as AVIF already — the big wins from re-compression come from your older or shared JPEGs, not from your newest shots.
Cleanor does this math for you — it finds the photos and videos eating your storage and compresses them on the device, with no uploads, so a full phone gets lighter without shipping your library to the cloud. Free on the App Store; Android edition in review. (See also our studies on what actually fills up phones, the apps people blame most and the geography of storage anxiety.)
Methodology
What we tested, and why two corpora
A single test set can't answer both "which format is fundamentally more efficient?" and "what happens when I compress the photos already on my phone?" — so we used two, on purpose:
- Corpus 1 — format efficiency (24 images): the Kodak True Color set, 24 lossless PNG images at 768×512 or 512×768. This is the standard reference corpus in image-compression research, covering varied natural scenes — portraits, landscapes, buildings and fine textures. Because the source is lossless (no prior compression to flatter or distort the result), it's a fair head-to-head test of how efficient each format is at its best.
- Corpus 2 — real-world re-compression (8 images): 8 real photographs at 12.2 megapixels (4032×3024), the native iPhone photo resolution. These are already-compressed JPEGs (mean source size 1.54 MiB, ≈1.62 MB), exactly like the photos sitting in your camera roll. This corpus tests what a cleaner app actually does: re-compress an existing JPEG, not encode a pristine master.
How we encoded
Every image was encoded to all three formats across an eight-step quality ladder — 40, 50, 60, 70, 80, 90, 95, 98 — for 768 encodes total (Kodak: 24 × 3 × 8 = 576; 12 MP: 8 × 3 × 8 = 192). All encoding ran through sharp 0.35.1 / libvips 8.18.3 — the same engine behind Cleanor's web tools — so the results reflect what you'd actually get, not a lab-only codec. The encoders were:
- JPEG — libjpeg-turbo (standard baseline JPEG)
- WebP — libwebp
- AVIF — libaom (AV1) at default effort 4
How we measured quality
For every encoded candidate we scored its quality against its own original using ffmpeg, capturing two metrics:
- SSIM (structural similarity) — the "All" channel, combining brightness and color. SSIM compares the structure of two images the way a person does — edges, textures and local patterns — rather than counting pixel-by-pixel differences. It runs from 0 to 1, where 1.0 is identical. As a rule of thumb, SSIM ≥ 0.98 is "visually lossless" for normal viewing: you won't see the difference from the original.
- PSNR (peak signal-to-noise ratio) — a more traditional engineering measure of raw error, where higher is better. We recorded it for every encode as a cross-check; it agreed with SSIM on the ranking of the formats, so we report the SSIM-based figures throughout.
The iso-quality method (why this is the only fair comparison)
You can't compare formats by giving them all "quality 80," because that number means something different in every codec. To compare apples to apples we used what's called an iso-quality ("same-quality") method: for each image and format, we interpolated the file size needed to land on a fixed SSIM target, then averaged across the corpus. That way every format is held to the same measured visual quality, and the only thing that varies is how many bytes it took to get there — which is exactly the number you care about for storage.
Why "quality 80" is a trap — the numbers. On the Kodak set at quality = 80, the three formats produced different sizes at different actual quality: JPEG 74.3 KB at SSIM 0.965, WebP 58.4 KB at SSIM 0.972, AVIF 83.8 KB at SSIM 0.982. AVIF's file is the largest of the three here — but only because it delivered the highest quality. Matched on the slider, the comparison is meaningless; matched on measured quality (iso-quality), AVIF is the smallest. Always compare at matched measured quality.
A quick quality-vs-size view (Kodak set)
For readers who like the full curve, here's the average file size per Kodak image at each slider setting, with the measured SSIM it actually achieved. Read down a column to see how quickly size grows; read across a row to see why the slider number isn't comparable:
| Quality setting | JPEG (KB / SSIM) | WebP (KB / SSIM) | AVIF (KB / SSIM) |
|---|---|---|---|
| 40 | 35.7 / 0.925 | 29.8 / 0.939 | 19.0 / 0.943 |
| 60 | 48.2 / 0.944 | 39.5 / 0.955 | 44.8 / 0.970 |
| 80 | 74.3 / 0.965 | 58.4 / 0.972 | 83.8 / 0.982 |
| 90 | 111.1 / 0.979 | 96.5 / 0.986 | 128.7 / 0.988 |
| 98 | 225.5 / 0.995 | 172.2 / 0.995 | 242.8 / 0.995 |
Plotted as a curve, the same data shows each format's "rate–distortion" trade-off — how many bytes it spends to buy each step of quality. The lower a line sits, the more efficient the format; where lines cross, the ranking flips:
The clearest takeaway: at any given slider value the three formats are simply not at the same quality, so their sizes can't be compared directly — which is exactly why we built every headline finding on iso-quality instead.
Reproduce it yourself
The whole study re-runs from free, open tools — no special data or licences:
- Get a test set. The lossless Kodak images (24 PNGs) are the research standard, or just use your own photos.
- Encode each one to JPEG, WebP and AVIF across a range of quality settings (we used 40–98). Any common toolkit works —
sharp/libvips, ImageMagick (magick), or the standalonecjpeg/cwebp/avifencencoders — and record each output's file size. - Score each result against its original with ffmpeg:
ffmpeg -i original.png -i candidate.avif -lavfi ssim -f null -(swapssimforpsnrto get PSNR too). - Compare at matched quality. For each format, find the file size that reaches a fixed SSIM (e.g. 0.98), then compare those sizes. That "same quality, fewer bytes" number is the entire result.
Our exact scripts (sharp encode + ffmpeg scoring + the iso-quality interpolation) and the raw 768-encode dataset back every figure above.
Limitations
SSIM is a single perceptual metric; we recorded PSNR alongside it as a cross-check and the two agreed, but every headline figure is SSIM-based. The Kodak set is lower-resolution, so its efficiency percentages are resolution-independent but its absolute sizes scale up with megapixels — which is why we ran the separate 12 MP corpus for real MB figures. On those real JPEGs, the very highest quality settings sat near the top of the measurable SSIM range, so the near-lossless (0.99) numbers are the least precise; the 0.95 and 0.98 results are firmer. AVIF here is libaom via libvips at default effort 4; a slower effort setting could shrink AVIF further still. And Apple's HEIC (HEVC), which iPhones use by default, has efficiency broadly similar to AVIF, so HEIC-to-AVIF re-compression yields smaller savings than JPEG-to-AVIF. All 12 MP sizes are reported in MiB (1,024² bytes). 768 encodes total. Cite freely with a link to this page.
FAQ
Which photo format saves the most space?
At the same visual quality, AVIF is the most efficient — about 36–52% smaller than JPEG depending on the quality level, and roughly 30% smaller even when re-compressing existing photos. WebP saves about 34% versus JPEG from a clean original, but can make high-quality photos larger if you re-compress existing JPEGs to it.
Is WebP smaller than JPEG?
From a pristine original, yes — WebP is about 34% smaller than JPEG at the same quality. But when re-compressing photos that are already JPEG (as on a phone), WebP at high quality can be 25–57% larger than an equal-quality JPEG. AVIF is the more reliable choice for shrinking existing photos.
How much smaller is AVIF than JPEG?
In our benchmark, AVIF needed 52% fewer bytes than JPEG at "good" quality (SSIM 0.95) and 36% fewer at high quality (SSIM 0.98). On real 12-megapixel photos at matched quality, AVIF was about 29% smaller than JPEG — roughly 1.0 MB versus 1.4 MB, with no visible quality loss. Measured against the original ~1.6 MB JPEG already on the phone, the saving is closer to 40%.
Does compressing photos lose quality?
Not visibly, if done right. We matched each format to the same measured quality (SSIM), so the smaller AVIF and WebP files look identical to the JPEG — the savings come from more efficient encoding, not from discarding visible detail.
What quality setting should I use?
Don't rely on the number — "quality 80" means different things in each format. Target a visual result (SSIM ≈ 0.98 is visually lossless for most photos) rather than a slider value, since the same number produces different sizes and quality across JPEG, WebP and AVIF.
What is SSIM, and why use it instead of the quality slider?
SSIM (structural similarity) is a 0-to-1 score for how close a compressed image looks to its original, judged by structure — edges, textures and local patterns — the way your eye does, where 1.0 is identical and 0.98 or above is "visually lossless." We used it because a format's "quality 80" setting produces a different actual SSIM (and a different file size) in JPEG, WebP and AVIF, so the slider can't fairly compare them. Holding every format to the same SSIM — the iso-quality method — is the only way to ask "same picture, same quality, how many bytes?"
Should I convert my iPhone photos, which are HEIC?
The big wins come from older or shared JPEGs, not your newest shots. HEIC (the HEVC-based format iPhones shoot by default) is already broadly as efficient as AVIF, so re-compressing HEIC saves much less than re-compressing JPEG. If your library is a mix, the JPEGs are where the space hides.