Image Compressor
Reduce image file size while maintaining visual quality
Drop images here or click to upload
Reduce file size for one image or many
Compression Settings
WebP usually compresses better than JPEG.
Why quality=80 is usually the right answer
JPEG encoding runs a discrete cosine transform (DCT) on every 8×8 pixel block, turning spatial pixel values into 64 frequency coefficients. The low-frequency coefficients describe broad tone, the high-frequency ones describe fine detail. Then a quantization table divides each coefficient and rounds — that's where bytes (and information) are thrown away. The "quality" slider scales that quantization table. At quality=100 the divisors are near 1 and almost nothing is lost; at quality=50 the high-frequency divisors climb past 20 and most of the fine detail collapses to zero.
The reason 80 is the conventional sweet spot isn't folklore — it's where the curve bends. On the Kodak Lossless True Color test set, moving from quality=100 to 80 typically drops file size by 65–75% while SSIM (structural similarity) stays above 0.97, which is below the threshold most viewers can detect in a side-by-side at normal viewing distance. Going from 80 to 60 only saves another ~15% but visibly introduces blocking on gradients (sky, skin). That's why Google's Lighthouse and Squoosh both default near q=75–80.
Two caveats worth knowing. First, PSNR is a poor quality proxy — it treats all pixel error as equal, but a 2 dB PSNR drop on a face is far more noticeable than on foliage; prefer SSIM or the newer Butteraugli/SSIMULACRA2 metrics if you're automating quality decisions. Second, the browser's canvas.toBlob('image/jpeg', 0.8) uses the browser's built-in encoder, which is not mozjpeg. Mozjpeg's trellis quantization squeezes another 10–15% at the same visual quality, so if you're compressing thousands of images for a CDN, run mozjpeg server-side instead of a browser tool like this one.