Moving a JPG from quality 85 to 95 more than doubled the file on all three of our test photos, 2.29 to 2.39 times the bytes. Save at 75 for anything people will look at on a screen, and at 85 if you’ll edit the file again or it’s a large, detailed photo shown at full size. We think almost nobody needs a JPG above 90, and a JPG at 100 still isn’t lossless.
Screenshots are the exception, and for them the answer is a different format rather than a different number.
Size and quality from 60 to 95
We saved three photos at four settings with MozJPEG, the JPG encoder in our image compressor, and scored each file against the original with SSIM on full-resolution brightness, averaged over 8×8 pixel windows every 4 pixels. A score of 1.0 means identical. The run was on 23 September 2026 in Chromium 153 on an Apple M5 Max laptop.
| Photo | Quality | Size | SSIM | Growth |
|---|---|---|---|---|
| 2816×1536 | 60 | 283 KB | 0.9140 | |
| 2816×1536 | 75 | 394 KB | 0.9296 | ×1.39 |
| 2816×1536 | 85 | 635 KB | 0.9463 | ×1.61 |
| 2816×1536 | 95 | 1,519 KB | 0.9768 | ×2.39 |
| 922×1152 portrait | 60 | 52 KB | 0.9523 | |
| 922×1152 portrait | 75 | 72 KB | 0.9640 | ×1.39 |
| 922×1152 portrait | 85 | 112 KB | 0.9734 | ×1.55 |
| 922×1152 portrait | 95 | 261 KB | 0.9857 | ×2.34 |
| 1408×768, from PNG | 60 | 68 KB | 0.9536 | |
| 1408×768, from PNG | 75 | 91 KB | 0.9636 | ×1.35 |
| 1408×768, from PNG | 85 | 141 KB | 0.9715 | ×1.54 |
| 1408×768, from PNG | 95 | 323 KB | 0.9843 | ×2.29 |
Each step up costs more bytes than the one before. From 60 to 75 the files grew by 35–39%; from 75 to 85 by 54–61%; from 85 to 95 they more than doubled. On the portrait and the photo that came from a PNG, the quality bought by those bytes shrank at the same time: the step from 60 to 75 added 0.010–0.012 of SSIM for about 37% more file, and the step to 85 added less (0.008–0.009) for about 55% more. That is where the curve bends, and it bends at 75. The big photo didn’t follow. Its SSIM kept climbing at every step, up 0.031 between 85 and 95, and at 75 it scored only 0.930, the lowest of the three. It is the largest and most detailed image in the set, and fine texture is exactly what the 8×8 windows punish when a JPG smooths it away. For a picture like that shown at full size, 85 earns its bytes. Shrink it first and the case for 85 mostly goes: our resizer brought the same photo to 1920 pixels wide at 315 KB, less than half the 635 KB of the full-size file at 85.
Lighthouse checks your JPGs at 85
Chrome’s Lighthouse audit “Efficiently encode images” takes every JPEG or BMP on a page, re-saves it at compression level 85, and flags it if that would save 4 KiB or more. So 85 is the ceiling a page audit expects, not a target. In our encoder the 85 files were 42–44% the size of the 95 files, far more than 4 KiB on any photo, so a page full of 95s will get flagged. Lighthouse’s encoder isn’t MozJPEG, and we haven’t checked how closely its 85 matches ours.
Google’s own format guide on web.dev names no setting at all. It says to “try several JPEG quality levels”, which is what the table above does.
A form with an upload limit turns the question around. Our compress-to-size tool searches for the highest JPG quality that fits under the limit, won’t go below 40, and makes the picture smaller in width and height instead once 40 is still too big. It lists the quality each file ended up at, so you can see where on the curve it landed.
The same number means something else in WebP and AVIF
Quality numbers are each encoder’s own scale. MozJPEG’s README doesn’t define its scale in terms of anything you could measure, and WebP and AVIF use different ones again. At 75, WebP files were 58–83% of the size of JPG 75 on our photos, but they scored slightly lower SSIM on all three.
AVIF’s scale sits so much lower that our tools translate it. Slider 50, 60 and 75 become libavif quality 33, 40 and 50; above 75 the slider moves AVIF two points per step, so 85 is 70 and 95 is 90. Even so, AVIF at slider 75 matched a JPG of the same SSIM in 43–53% of the bytes. The full comparison, with WebP, is in AVIF vs WebP vs JPG, measured.
100 is not lossless
JPG has no lossless setting. MDN describes the format simply as lossy, and our own test agrees. At quality 100, MozJPEG turned the photo saved as PNG into an 859 KB file, 2.7 times the size of the 95 version, and 82% of its pixels still differed from the original, by at most 4 levels out of 255. SSIM was 0.998. That is close to invisible and still not the original.
The screenshot of a page of text went further: at 100 the JPG came to 625 KB, 2.4 times the PNG it came from, with 97.6% of pixels changed. If you need the exact pixels, save PNG, or WebP or AVIF at 100, which our tools switch to their lossless modes. Re-saving a JPG at 100 doesn’t put back anything an earlier save took out either.
Screenshots and text
No JPG setting fixes a screenshot.
On our 1200×1600 page of text, JPG at 95 scored 0.9969 SSIM at 342 KB. WebP at 75 scored 0.9972 at 98 KB. The JPG was 3.5 times the size and still slightly worse, and at 95 both of our screenshots came out larger than the PNGs they started as (128% and 129%). At quality 90, PNG to JPG saved them only 3–4%.
Sharp edges and flat colour are what JPG handles worst, whatever the number. Use PNG to WebP for screenshots: at 85 it cut ours by 51–55%.
What we haven’t measured
Three photos, all already compressed before we started. None came off a camera with its sensor noise intact, and noise is where JPG spends bytes fastest, so the bend could sit elsewhere on a raw phone photo. SSIM is also a formula, not a viewer: we haven’t run a side-by-side test with people to find the setting where they stop seeing a difference.