Almost every guide to shrinking a photo tells you to lower the quality slider. That advice is not wrong, but it is aimed at the smaller of the two levers you have. To show the difference rather than assert it, we took one photograph and compressed it forty different ways, measuring the result each time.
The test
The test image is Track on Fremington Edge by Kreuzschnabel (CC BY-SA 3.0): a 4608 × 3456 landscape photo, 15.9 megapixels, 9.21 MB as downloaded. It is a realistic worst case — fine detail in grass and stone is exactly what compression struggles with.
Every number below was produced by Chrome 153's own JPEG and WebP encoders, which is the same encoder the tools on this site use, on the same machine, in one run. Nothing is estimated.
Lever one: quality
Quality decides how much detail the encoder throws away. Here is the full-size photo at eleven quality settings:
| Quality | JPEG | WebP | vs original |
|---|---|---|---|
| 100 | 15.3 MB | 18.5 MB | larger |
| 95 | 6.0 MB | 5.3 MB | −35% |
| 90 | 4.3 MB | 3.8 MB | −53% |
| 85 | 3.5 MB | 2.9 MB | −62% |
| 80 | 2.9 MB | 2.4 MB | −68% |
| 75 | 2.6 MB | 2.0 MB | −72% |
| 70 | 2.3 MB | 1.9 MB | −75% |
| 60 | 1.9 MB | 1.7 MB | −79% |
| 50 | 1.7 MB | 1.5 MB | −82% |
| 40 | 1.5 MB | 1.3 MB | −84% |
| 30 | 1.2 MB | 1.0 MB | −86% |
Two things stand out. First, quality 100 produced a file 66% larger than the original. Re-encoding a photo at maximum quality does not preserve it — it re-encodes detail that has already been discarded once, and spends bytes describing the previous encoder's artefacts. If you ever export at “maximum” to be safe, this is what you are paying for.
Second, the curve flattens fast. Going from 90 to 80 saves 1.4 MB; going from 50 to 40 saves 0.2 MB and costs visible damage. Below about 60, you are paying real quality for small gains.
Lever two: dimensions — and it is the bigger one
File size scales with the number of pixels, and pixel count scales with the square of the width. Halving the width quarters the pixels. Here is the same photo at one fixed quality (80) and different widths:
| Width | Pixels | JPEG at quality 80 | vs full size |
|---|---|---|---|
| 4608 px (original) | 15.9 MP | 2,999 KB | — |
| 2048 px | 3.1 MP | 647 KB | −78% |
| 1600 px | 1.9 MP | 408 KB | −86% |
| 1280 px | 1.2 MP | 259 KB | −91% |
| 1024 px | 0.8 MP | 163 KB | −95% |
| 800 px | 0.5 MP | 103 KB | −97% |
| 640 px | 0.3 MP | 65 KB | −98% |
Resizing to 2048 px wide — still larger than most laptop screens can show — saved 2.35 MB. Dropping quality from 80 all the way to 30 at full size saved 1.7 MB and made the photo visibly worse. The lever most articles talk about is the weaker one.
This is why Resize Image is often the right tool when you think you need a compressor, and why Compress Image to Target Size reduces dimensions as well as quality when a target is small enough to demand it.
The re-saving myth, measured
“Every time you save a JPEG it loses quality” is repeated everywhere. We tested it: take the 2048 px version, decode it, re-encode at quality 80, and repeat ten times, measuring the difference from the first save each round.
| Save | File size | PSNR vs source | Mean pixel error |
|---|---|---|---|
| 1st | 751.8 KB | 32.6 dB | 3.89 |
| 2nd | 752.8 KB | 32.6 dB | 3.90 |
| 5th | 752.7 KB | 32.5 dB | 3.91 |
| 10th | 752.8 KB | 32.5 dB | 3.91 |
After ten round trips the image is essentially unchanged: 0.1 dB of PSNR and 0.02 levels of average pixel error. The first save does nearly all the damage; the rest mostly re-encode the same already-quantised blocks.
The myth is not baseless, though — it just needs conditions. Generation loss becomes real when something changes between saves: a different quality setting, a resize, a crop that shifts the 8×8 block grid, a rotation, or a different encoder. Editing and re-saving repeatedly does degrade a photo. Opening and saving it again at identical settings does not, and there is no reason to hoard “original” copies out of fear of the save button alone.
KB, KiB, and why a “100 KB” file gets rejected
Upload forms are where this stops being academic. A form that says “maximum 100 KB” usually means 100,000 bytes, because that is what the server-side check counts. Windows and macOS, however, show file sizes in a mix of conventions, and plenty of tools treat 1 KB as 1,024 bytes — so a file your computer calls “100 KB” can be 102,400 bytes and be refused.
The safe move is to aim under the round number in bytes: target 95 KB for a 100 KB limit, 950 KB for a 1 MB limit. The KB-target tools on this site (100 KB, 200 KB, 1 MB) treat “N KB” as at most N × 1,000 bytes for exactly this reason.
What to actually do
| Where it is going | Do this | Expect |
|---|---|---|
| Email attachment | Resize to 1600 px, quality 80 | ~400 KB per photo |
| A web page or blog post | Resize to 1280–1600 px, then WebP | ~200–350 KB |
| An upload form with a KB limit | Use a target-size tool, aim 5% under | Exactly under the cap |
| Chat apps | Resize to 1280 px before sending | Beats the app's own re-compression |
| Printing at 10 × 15 cm | Keep 1800 px on the long edge, quality 90 | ~1 MB, no visible loss |
| Archiving the original | Do not re-encode at all | Keep the file you started with |
Three things that do not help
- Renaming the extension. Calling a JPEG
.webpchanges nothing about its contents; it only makes the file harder to open. - Zipping a photo. JPEG, PNG, WebP and AVIF are already compressed. A ZIP of a JPEG is typically within 1–2% of the original size, and sometimes larger.
- Stripping metadata to save space, on its own. Removing EXIF is worth doing for privacy, but on a multi-megabyte photo it usually saves a few dozen kilobytes — well under 1%.
If you want to check any of this yourself, the measurements above take about two minutes to reproduce: the source photo is linked at the top, and every tool used runs in your browser without uploading the file anywhere.