Updated September 2026
A photo straight off a modern phone is often 5–15 MB. That's fine for local storage, but it's too big for a lot of everyday uses: an email attachment limit, a website's upload cap, a contact form, or just a page that loads slowly because of oversized images. Compression re-encodes the photo at a smaller file size — here's what's actually happening when you move that quality slider.
Lossy compression (JPG, WebP) throws away some image detail — usually detail the human eye barely notices — to shrink the file dramatically. Lossless compression (PNG) keeps every pixel exactly as-is and only removes redundancy in how the data is stored, which means much smaller savings but zero quality loss. Most photos compress best as lossy; graphics with flat colors, text, or transparency (screenshots, logos, diagrams) usually compress better and look cleaner as lossless PNG.
The Compress Image tool on this site uses the browser's own canvas.toBlob() re-encoder with a quality value from 0.3 to 1.0. At the high end (0.9–1.0), the encoder keeps nearly all the fine detail — file size drops modestly. At the low end (0.3–0.5), it discards much more detail in areas of subtle color variation (skies, skin tones, gradients) while keeping sharp edges mostly intact, which is why low-quality JPGs show visible blocky artifacts first in smooth areas rather than in fine texture. There's no single "correct" setting — it's a direct trade: lower number, smaller file, more visible loss.
The tool also has a separate max width/height setting, which is a completely different kind of saving: it reduces the actual pixel dimensions of the image before re-encoding, rather than just how efficiently those pixels are stored. For a photo destined for the web (where a 4032×3024 phone photo is wildly oversized for almost any page layout), capping the dimension to something like 1920px often cuts file size far more than the quality slider alone — and for on-screen viewing, there's no visible loss at all, since the extra resolution wasn't being displayed anyway.
In practice, a typical phone photo compressed with a moderate quality setting (0.6–0.75) and no resizing lands 60–90% smaller with little visible change on a screen. Add a max-dimension cap and the savings can go well beyond that for images that were oversized to begin with. WebP generally compresses better than JPG at an equivalent visual quality — it's a newer format built specifically to improve on JPG's efficiency — though JPG remains the safer choice if the receiving end (an older tool, a specific upload form) doesn't explicitly support WebP.
Take a typical 12 MB phone photo at its native 4032×3024 resolution. Re-encoded as JPG at quality 0.7 with no resize, it commonly lands around 1.5–2.5 MB — already a 75–85% reduction. Add a resize to 1920px on the long edge (still large enough to fill most screens) and the same photo often drops to 300–600 KB, because pixel count and file size scale roughly together for a fixed quality setting: half the linear dimensions means roughly a quarter the pixels to encode. That combination — modest resize plus a mid-to-high quality setting — is usually where the best size-for-visible-quality trade-off lives, rather than pushing the quality slider to its lowest setting on a full-resolution image.
All of it — the resize, the re-encode, the quality trade-off — runs on an in-browser <canvas> element inside your own browser tab. No photo is uploaded to compress it; the original file never leaves your device, and the compressed output is generated and downloaded (or zipped, for a batch) locally. That also means there's no server-side file-size limit to hit — the only constraint is what your own device's memory can handle.
Will compressing multiple times make the file smaller each time? No — re-compressing an already-lossy file mostly adds more quality loss without much further size reduction ("generation loss"). Always compress from the original, not from a previously compressed copy.
What quality setting should I use for email? 0.6–0.7 with a max dimension around 1600–1920px comfortably clears most email attachment limits while looking fine on screen.
Does compression remove EXIF/GPS metadata too? The canvas re-encoding process used here does drop metadata as a side effect — if privacy is the specific goal, though, use the dedicated Remove EXIF tool, which is built and worded around that use case.