The short answer: with the file size fixed at 100 KB, AVIF gave the closest match to the original on 19 of our 20 phone photos and WebP on the other one. JPG never came first. The median SSIM was 0.880 for JPG, 0.904 for WebP and 0.922 for AVIF. The price is time: in the browser, the AVIF result took a median 65 seconds against about 1 second for JPG, and WebP about 13 seconds. And since many upload forms only take JPG, the format you can use often matters more than the one that scores best.
What we did
We took 20 phone photos from our test set, between 9 and 49 megapixels and 1.4 to 26 MB each, and compressed every one to 100 KB three times: as JPG, as WebP and as AVIF. Each run used the same strategy as our compress to 100 KB tool: search for the highest quality between 0.50 and 0.95 that fits the budget, and if even 0.50 is too big, scale the photo down and search again. The budget is decimal, so 100 KB means 100,000 bytes. All 60 files came in under it.
Our compress-to-size pages only produce JPG. The WebP and AVIF runs are a lab test of the same strategy with a different encoder, to answer the question people ask us: would another format do better at the same size?
The results per format
| JPG | WebP | AVIF | |
|---|---|---|---|
| Under 100,000 bytes | 20 of 20 | 20 of 20 | 20 of 20 |
| Median file size | 99,102 bytes | 99,580 bytes | 97,367 bytes |
| Median output size | 0.77 MP (978 px wide) | 0.99 MP (1,062 px wide) | 1.06 MP (1,091 px wide) |
| Median quality chosen | 0.57 | 0.65 | 0.54 |
| Median SSIM (range) | 0.880 (0.694–0.981) | 0.904 (0.735–0.983) | 0.922 (0.752–0.986) |
| Highest SSIM of the three | 0 photos | 1 photo | 19 photos |
| Median time (range) | 1.1 s (0.6–3.0 s) | 12.9 s (8.3–116.7 s) | 65.4 s (32.0–163.3 s) |
Every photo had to be scaled down in every format. A 12-megapixel phone photo is far too big for 100 KB at any reasonable quality, so the main thing that changes between formats is how many pixels survive. Compared photo by photo, WebP kept a median 1.26 times as many pixels as JPG and AVIF 1.33 times. That's why their quality settings are not much higher than JPG's: the extra efficiency went into resolution rather than quality.
The order was consistent. AVIF beat JPG on all 20 photos, WebP beat JPG on 19, and AVIF beat WebP on 19. The full order AVIF, then WebP, then JPG held on 18 of the 20. The median gains, photo by photo, were 0.034 SSIM for AVIF over JPG, 0.020 for WebP over JPG and 0.014 for AVIF over WebP.
AVIF also tended to stop further below the line. Its median file was 2,634 bytes under the budget, and the smallest was 94,037 bytes.
All 20 photos
| Photo | Original | JPG (px, SSIM) | WebP (px, SSIM) | AVIF (px, SSIM) | Best |
|---|---|---|---|---|---|
| Gilded church interior, Barcelos | 12.2 MP | 611 × 814, 0.694 | 609 × 812, 0.735 | 619 × 826, 0.752 | AVIF |
| Apartment blocks, lawn and sky | 12.2 MP | 903 × 677, 0.852 | 933 × 700, 0.884 | 912 × 684, 0.892 | AVIF |
| Basilica interior, Boston | 22.0 MP | 956 × 716, 0.881 | 1,044 × 781, 0.901 | 1,179 × 884, 0.932 | AVIF |
| Iced coffee on a café table | 12.2 MP | 1,316 × 1,754, 0.975 | 1,959 × 2,612, 0.976 | 2,722 × 3,629, 0.981 | AVIF |
| Wooden church, cloudy sky | 9.4 MP | 1,112 × 840, 0.922 | 1,463 × 1,105, 0.938 | 1,496 × 1,130, 0.954 | AVIF |
| Office tower at night, Shanghai | 12.2 MP | 953 × 1,272, 0.942 | 1,352 × 1,802, 0.943 | 1,712 × 2,283, 0.954 | AVIF |
| New apartment buildings, street | 19.2 MP | 1,046 × 780, 0.876 | 1,154 × 859, 0.907 | 1,204 × 897, 0.926 | AVIF |
| Coffee cup on a balcony table | 12.2 MP | 1,571 × 1,179, 0.981 | 2,381 × 1,787, 0.983 | 3,470 × 2,603, 0.986 | AVIF |
| Cemetery under grey sky, Białystok | 12.2 MP | 922 × 1,230, 0.907 | 1,079 × 1,440, 0.925 | 1,013 × 1,350, 0.942 | AVIF |
| Block of flats and trees, Chatham | 15.4 MP | 924 × 674, 0.829 | 941 × 687, 0.852 | 1,016 × 741, 0.866 | AVIF |
| Neoclassical façade, Moscow | 48.8 MP | 1,009 × 756, 0.880 | 1,033 × 775, 0.901 | 1,072 × 804, 0.918 | AVIF |
| Shopping mall atrium | 24.5 MP | 1,007 × 755, 0.882 | 1,150 × 863, 0.912 | 1,109 × 832, 0.915 | AVIF |
| Rock and grass, close-up | 9.1 MP | 581 × 1,033, 0.824 | 616 × 1,095, 0.852 | 673 × 1,196, 0.869 | AVIF |
| Lake with paddleboarder, Białystok | 12.2 MP | 1,297 × 972, 0.958 | 1,621 × 1,217, 0.958 | 1,575 × 1,181, 0.974 | AVIF |
| Ruined stone church, Caltabellotta | 12.2 MP | 1,000 × 750, 0.871 | 950 × 713, 0.869 | 775 × 581, 0.872 | AVIF |
| Warship and armoured vehicle on a quay | 12.2 MP | 1,269 × 953, 0.963 | 1,616 × 1,211, 0.966 | 1,959 × 1,469, 0.979 | AVIF |
| Stone observation tower, Aulanko | 9.1 MP | 613 × 1,090, 0.780 | 645 × 1,145, 0.827 | 513 × 913, 0.814 | WebP |
| Crowd at an outdoor event | 12.2 MP | 1,247 × 936, 0.956 | 1,595 × 1,196, 0.966 | 1,543 × 1,157, 0.975 | AVIF |
| Brick terrace house, London | 12.2 MP | 644 × 859, 0.709 | 661 × 881, 0.750 | 668 × 892, 0.772 | AVIF |
| High-rise tower, Helsinki | 24.8 MP | 665 × 1,183, 0.832 | 773 × 1,376, 0.867 | 924 × 1,643, 0.903 | AVIF |
_-_Igreja_de_Nossa_Senhora_do_Ter%C3%A7o_01.jpeg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
_with_windows_and_a_high_brick_wall,_viewed_from_Old_Road_in_Chatham,_Kent.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
_Mar_28,_2026.jpg){kind=link}
Busy photos and calm photos behave differently
How much the format helped depended on the scene. On busy photos, full of fine detail such as the gilded church interior and the brick house, every format had to shrink the photo hard, and all three ended up at about the same size. On calmer scenes with large smooth areas, like the coffee cups, the quayside and the night-time tower, WebP and AVIF kept far more pixels than JPG. The table splits the 20 photos into two halves by how many pixels the JPG kept.
| Group (10 photos each) | JPG | WebP | AVIF | Pixels vs JPG (WebP / AVIF) |
|---|---|---|---|---|
| Busy: JPG kept 0.50–0.76 MP | 0.65 MP, SSIM 0.840 | 0.68 MP, SSIM 0.861 | 0.69 MP, SSIM 0.870 | 1.06× / 1.10× |
| Calm: JPG kept 0.76–2.31 MP | 1.19 MP, SSIM 0.949 | 1.93 MP, SSIM 0.951 | 1.82 MP, SSIM 0.964 | 1.63× / 1.87× |
The extremes are large. On the coffee cup on a balcony table, AVIF kept 3,470 × 2,603 pixels, 74% of the original, while JPG kept 1,571 × 1,179, so AVIF had 4.9 times as many pixels. On the iced coffee it was 4.3 times. On the gilded church interior, all three came out at about 610 × 815 pixels, and the three SSIM scores (0.694, 0.735, 0.752) were the lowest in the test.
There's a catch in how we score. SSIM is measured at 1,080 px wide, so pixels beyond that don't count. On the calm photos, AVIF's extra resolution barely moved the score: on the balcony coffee cup it was 0.986 against JPG's 0.981. Those extra pixels only matter if the image is shown large, zoomed into or cropped. The largest SSIM gain came on the Helsinki high-rise, where AVIF kept 1.9 times JPG's pixels and scored 0.903 against 0.832.
Two photos went against the trend. On the ruined church and the observation tower, AVIF kept fewer pixels than JPG (0.6 and 0.7 times) at a higher quality setting (0.69 and 0.66). The strategy's scale-down step is an estimate, and with AVIF it shrank these two further than it needed to. On the ruined church the three scores were within 0.003 of each other. The observation tower is the one photo where WebP won: at 645 px wide against AVIF's 513 px, it kept visibly more texture in the stonework.
What the differences look like
We enlarged parts of the gilded church, the brick house, the Moscow façade and the observation tower to compare the three files side by side. At normal viewing size, the three versions of a photo looked much alike; the differences showed when enlarged. The JPGs had blocky texture and muddy colour in dark, detailed areas, such as the shadowed brickwork and the painted ceiling panels. WebP was smoother there and slightly softer. AVIF had the cleanest edges, for example around the white door arch and the column flutes, but it smoothed fine texture into flat patches, so the painted panels lost detail rather than gaining blocks. None of the formats keeps the detail of a 12-megapixel photo in 100 KB; they differ in how they lose it.
Speed: JPG is far faster
JPG is encoded by the browser itself, while WebP and AVIF ran through libwebp and libavif compiled to WebAssembly. Hitting a size target needs many encodes, one per step of the quality search and again after each scale-down, so the encoder speed is multiplied. Photo by photo, WebP took a median 12 times as long as JPG and AVIF 61 times. The slowest was the 49-megapixel Moscow photo: 2.6 seconds for JPG, 116.7 seconds for WebP and 163.3 seconds for AVIF. A single conversion at a fixed quality is much faster; in our format conversion test, one AVIF encode of a 1600 × 1200 photo took about 7 seconds.
Which format to use
- The upload form says JPG, or doesn't say. Use JPG. Many government, job and exam portals accept only JPG. An AVIF that scores better is no use if it's rejected. Our compress to 100 KB tool outputs JPG, and in this test every result was under 100,000 bytes in a median 1.1 seconds.
- You control where the image is shown. For your own website or app, WebP gave a small but steady gain over JPG at this size and is supported by every current browser. It won against JPG on 19 of 20 photos.
- You want the most from every byte and can wait. AVIF came out ahead on 19 of 20 photos, by the widest margin on calm scenes, where it kept up to 4.9 times the pixels. Check that the place you're uploading to accepts AVIF before you use it.
- The photo is busy and detailed. No format helps much at 100 KB: on our two busiest photos, all three results were between 609 and 668 px wide and scored below 0.78 SSIM. If the result looks too rough, crop to what matters before compressing; a smaller area leaves more bytes per pixel.
For the background on the three formats, see AVIF vs WebP vs JPG. For why a 100 KB limit can mean 100,000 or 102,400 bytes, see KB or KiB.
How we tested
On 24 October 2026 we ran each of the 20 phone photos through the compress-to-size strategy in Chromium on an Apple M2 Mac, once per format. The strategy is the one in our compress-to-size tool: a binary search for the highest quality between 0.50 and 0.95 that keeps the file at or under 100,000 bytes, and if quality 0.50 is still too big, a scale-down by a factor estimated from that file's size, then a new search. JPG used the browser's own canvas encoder, as the tool does. WebP and AVIF used libwebp and libavif compiled to WebAssembly (the @jsquash packages), also running in the browser. The photos are described in our editorial policy and the general method in how we test the tools.
For each output we recorded its size in bytes, its dimensions, the quality the search chose and the time from choosing the file to the result. For SSIM we scaled the original and the output to 1,080 px wide and compared their luminance; 1 means identical.
Limits: 20 photos is a small sample, though larger than the 6-photo format comparison on our compress-to-size pages. That smaller run gave median SSIMs of 0.866, 0.888 and 0.905 for JPG, WebP and AVIF at 100 KB, the same order as here. All times come from one machine and one browser; in Safari, JPG and AVIF come from Safari's own encoders, and a slower phone will take longer. SSIM looks only at brightness, not colour, and at 1,080 px wide it ignores resolution beyond that, so it understates the benefit of AVIF's and WebP's extra pixels on calm photos. It also doesn't always match what people see. The quality search takes seven steps, so the chosen quality is close to, but not exactly, the highest that fits. And this is one target: at 50 KB or 200 KB the gaps will be different.