🗜️ Image Compressor
Reduce image file size right in your browser — no upload, no server, completely private.
How Image Compression Actually Works — and Why the Numbers You See Online Are Often Misleading
Every time someone publishes a "top 10 image compression tips" article, they repeat the same advice: drop your quality to 80%, save as WebP, done. That guidance is not wrong, but it misses the most useful parts of the story — the mechanics that explain why a 150 KB JPEG at quality 75 can look sharper than a 300 KB PNG, or why converting a screenshot to WebP sometimes makes it larger, not smaller.
Understanding what actually happens inside a compressor turns a guessing game into a reliable workflow.
The Two Fundamentally Different Types of Compression
All image compression falls into one of two categories: lossless and lossy. They accomplish completely different things and the right choice depends on the image's purpose, not just its size.
Lossless compression reorganises data so the same pixel values can be reconstructed perfectly. PNG uses a combination of delta filters (recording the difference between adjacent pixels rather than absolute values) followed by DEFLATE compression, the same algorithm behind ZIP files. A PNG of a solid white rectangle compresses to almost nothing because the differences between every pixel are zero. A photograph compressed as PNG barely shrinks because the pixel-to-pixel variation is high and unpredictable.
Lossy compression, used by JPEG and WebP, actually discards information — permanently. JPEG converts pixel blocks into frequency components using a Discrete Cosine Transform (DCT), then quantises those components: low-frequency components (broad gradients, flat colours) are kept at high precision; high-frequency components (sharp edges, fine texture) are rounded more aggressively. The quality setting controls exactly how aggressively this rounding happens. At quality 95, almost nothing is rounded. At quality 60, many fine details are averaged away and the file becomes a fraction of the original size.
This is why lossy compression is unsuitable for screenshots, diagrams, logos, or any image with hard-edged text. Those images are dominated by high-frequency detail, and any rounding creates the characteristic "blockiness" of over-compressed JPEG.
What Happens When You Adjust the Quality Slider
The quality slider in a JPEG encoder is not a linear percentage of the original file size. It is a scaling factor applied to the quantisation table — a 64-value matrix that controls how much each DCT coefficient is rounded. The relationship between quality and file size follows a roughly exponential curve.
Research from Guetzli, Google's perceptual JPEG encoder, showed that for most natural photos, quality settings between 70 and 85 represent the optimal tradeoff zone: file sizes are roughly 30–60% smaller than quality 95, but the structural similarity index (SSIM) compared to the original is still above 0.97. Below quality 65, most people begin to notice compression artefacts even when not actively looking for them. Above quality 88, the file size increase per visible quality improvement becomes steep enough that it is rarely worth it for web delivery.
WebP, which uses a more modern compression algorithm based on VP8 video encoding, achieves the same perceptual quality as JPEG at roughly 25–35% smaller file sizes, according to Google's 2010 benchmark and subsequent independent studies. The savings are real, though they vary significantly by image type — the gains are largest on photographic content and smallest on flat-colour illustrations.
Why PNG Is Almost Never the Right Format for Photographs
PNG's lossless compression is a feature that becomes a liability for photographic images. A 12-megapixel RAW photo converted to PNG will typically be 15–30 MB. The same photo saved as JPEG at quality 80 will be 3–5 MB. The same photo saved as WebP at quality 80 will be 2–4 MB. The pixel-to-pixel variation in photographs overwhelms PNG's delta filtering, leaving very little redundancy for DEFLATE to exploit.
Where PNG genuinely wins is in images with exact colours, transparent backgrounds, or hard-edged text. A company logo, an icon, a UI screenshot, a QR code — these compress extremely well as PNG and retain perfect sharpness. Saving them as JPEG introduces ringing artefacts around every edge, which is why low-resolution JPEG logos often look blurry even at large file sizes.
The Hidden Cost: Decode Time and Memory
File size is only half the performance story. When a browser downloads an image and renders it, it must decode the compressed data back into raw pixel values — and that decoded bitmap lives in memory regardless of the original file format.
A 4000 × 3000 pixel image occupies exactly 45.8 MB of GPU memory (4000 × 3000 × 4 bytes per RGBA pixel), whether the original file was 2 MB or 200 KB. This is why oversized images at high resolution are expensive even when the file is small. A 200 KB WebP at 4000 × 3000 pixels will still consume far more memory than a 400 KB JPEG at 1200 × 900 pixels. Resizing before compressing almost always outperforms compressing without resizing.
Real-World Benchmarks: What Compression Ratios to Expect
Based on testing across categories of common web images:
- Natural photographs (landscapes, portraits, product shots): JPEG quality 75 typically yields 60–80% size reduction vs. uncompressed. WebP quality 75 adds another 25–30% reduction over JPEG. Total savings from original capture to web-ready WebP: often 85–95%.
- Screenshots of UIs: PNG compression achieves 40–70% reduction. Converting to JPEG quality 80 usually saves further but introduces visible artefacts around text. WebP at quality 80 handles these better than JPEG, maintaining text sharpness at half the PNG file size.
- Flat-colour illustrations: PNG is usually optimal. JPEG compression introduces colour banding on gradient backgrounds and fringing on solid-colour regions.
- GIF animations: Each frame is limited to 256 colours, making GIFs very poor for photographic content. For simple animations, WebP animation or video (even a short MP4) will typically be 50–90% smaller than the equivalent GIF.
The Perceptual Gap: Why File Size and Quality Are Not Opposites
One of the most practically useful findings in image compression research is that perceptual quality does not degrade uniformly with compression. Human vision is more sensitive to changes in luminance (brightness) than in chrominance (colour), and more sensitive to changes in flat areas than in textured regions. JPEG exploits this by using chroma subsampling — reducing the resolution of colour information by half in one or both dimensions.
This means a photograph can lose all its colour resolution and most people will not notice. It also means compression artefacts are most visible in smooth gradients (sky, skin, solid backgrounds) rather than in busy, textured areas (hair, grass, fabric). If your image has a large, smooth sky, you need to be more conservative with compression than if the same file size comes from a complex forest scene.
Choosing Your Target Quality Setting
There is no universal correct quality number. The right setting depends on the viewing context:
- Social media thumbnails (displayed at 200–400px): quality 65–70 is indistinguishable from quality 90 at those sizes. Aggressive compression makes sense.
- Full-bleed hero images (displayed at 1400px or wider): quality 78–84 is usually the safe zone where savings are substantial and artefacts remain invisible.
- Product shots where fine detail matters (fabric texture, jewellery, electronics): quality 82–88 is conservative enough to avoid perceptible rounding.
- Print-ready or archival images: use lossless formats and apply no lossy compression, regardless of file size.
The most reliable approach is always to use the lowest quality setting at which the image looks correct at its intended display size. Never set quality by a fixed number without checking the output visually — the same setting produces very different results on different image content.
Browser-Side Compression: What Is Actually Possible
Modern browsers expose the Canvas API, which allows JavaScript to draw an image onto a canvas and export it as a new JPEG or WebP at a specified quality level. This is exactly how client-side image compressors work — no server needed, no privacy risk, no upload latency. The limitation is that the browser's built-in encoder quality is competent but not best-in-class: it will not match specialised encoders like MozJPEG or the Squoosh CLI for the same file size target, but for most use cases the difference is within 10–15% of file size and visually negligible.
The canvas approach also loses EXIF metadata (camera model, GPS coordinates, copyright) since the exported file is a freshly encoded image. For workflows where metadata matters, a server-side tool or a dedicated app is a better fit. For quick web optimisation, the browser compressor covers 90% of real-world needs instantly.