How to reduce an image size without losing quality

Three numbers decide whether an image is too big: the image file size in bytes, the pixel dimensions, and the ceiling the recipient's system will accept. Reducing the image file size — what people usually mean when they say reduce an image size — is the cheapest of the three, and very often it is enough. A smaller file that still opens sharply beats a smaller picture that nobody asked for.

Why an image ends up large in the first place

File size is not a single number. It is the sum of five independent things, and only some of them are the encoder's fault. If you compress an 8 MB photo and it barely moves, one of these is already told you that there is nothing left to take:

1. The container format is wrong for the content. A photograph saved as PNG is the classic case — PNG never discards a pixel, so it cannot meaningfully shrink a picture that was never meant for it. The same pixels as WebP or AVIF came out 90% and 93% smaller in our measurements.
2. The resolution is bigger than the job. A 6000 px photo for a 400 px slot carries roughly 225 million pixels nobody will ever look at.
3. The quality was set by a menu, not by a measurement. A fixed "quality 80" treats a smooth sky and a photo of tree branches identically, which is exactly backwards.
4. Metadata is riding along. EXIF blocks, embedded thumbnails, GPS traces and maker notes can add tens of kilobytes on their own without a single visible pixel changing.
5. The file is already at the floor. Well-optimised sources resist re-encoding, and the honest answer then is to change format rather than to re-save the same pixels again.

The five levers, cheapest first

Work down this list and stop the first time you hit the budget. Every one of these is available in the browser compressor, and every one of them runs on your own machine — nothing is uploaded at any point.

1. Change format. Encoding to AVIF needs about 26% fewer bytes than MozJPEG to reach the same measured fidelity, which makes it the single biggest lever available. WebP is the safer choice for compatibility and came out roughly level with JPEG at equal fidelity — a little smaller on two of three test images, clearly larger on a highly detailed one. A PNG screenshot is the best case of all: 100 KB became 26 KB as WebP and 4 KB as AVIF.
2. Let quality be measured, not guessed. A good encoder encodes a small test pass at several quality levels, scores each against the original, and keeps the smallest file that still clears a fidelity floor around 40 dB PSNR — close to where differences stop being visible at normal viewing sizes. Our camera-JPEG test set came out 38% smaller that way.
3. Quantise PNG. Screenshots, diagrams and flat illustrations rarely need 16.7 million colours. Reducing one to 80 colours took a 100 KB PNG to 30 KB with no visible banding; 256 colours is the safer default for graphics with gradients.
4. Drop the metadata. Re-encoding copies pixels only, so EXIF, GPS and embedded thumbnails go with it. Apply the orientation tag first, or the file comes back sideways.
5. Only then consider pixels. Downscaling is the lever people reach for first and the one that costs the most. When it is unavoidable, halve the image repeatedly rather than shrinking in one step — repeated halving preserves edge structure, which lets the encoder spend fewer bits for the same perceived quality.

What each lever is actually worth

When a form only accepts a specific size

Upload limits, job portals, marketplaces and CMS media libraries usually quote a hard ceiling rather than asking for "better quality". Pick the ceiling you are fighting and let the engine search for it:

• 50 KB — signatures, stamps, icons and attachments that must survive a chat app thumbnail.
• 100 KB — a photo that has to sit inline in a form or a ticket upload.
• 200 KB — the default chat and email-preview budget; the target size field defaults to this.
• 500 KB — the headroom budget for job portals and media libraries.
• A whole email — bring an album to one consistent size and take it as a single ZIP.

What the numbers were measured on

Three 2400×1600 photographs, each in three states: already optimised, re-encoded at Q96 to stand in for a straight-from-camera file, and stored losslessly as a 3 MB PNG — plus one 1440×900 interface screenshot generated in the browser so it is identical on every run. Fidelity is PSNR on luma, measured the same way the engine's own quality search measures it. Encoders are MozJPEG (WebAssembly) for JPEG and the @jsquash builds for WebP and AVIF; a case that silently fell back to a browser-native encoder is never published as a WebAssembly result. Every case is encoded twice and only the second pass is reported, because a cold-start number would misdescribe normal use.

Two caveats worth knowing. AVIF is by far the slowest encoder here and its quality search can hit its patience budget on a loaded machine, so its figures are the least stable in the table. And a file that is already well optimised cannot be improved at this fidelity — the engine returns your original rather than shipping something larger. Measured 2026-09-20.

Frequently asked questions