Updated September 2026
"Compress without losing quality" is a common ask, and the honest answer is a little more nuanced than a single setting: there's a real difference between zero pixel loss (true lossless) and no visible loss (lossy compression tuned so the difference isn't noticeable). For almost every practical purpose — email, web, forms — the second is what you actually want, and it can shrink a file dramatically more than true lossless ever will.
The Compress Image tool gives you two independent ways to shrink a file, and mixing them up is the most common reason people get worse results than they expect:
In practice, resizing first is usually the higher-leverage move: a 4032×3024 phone photo capped to 1920px wide, then compressed at a high quality (0.85–0.9), is often smaller and visually cleaner than the same photo left at full resolution and squeezed down purely via a low quality setting.
Lossy compression doesn't degrade an image evenly — it targets the parts the eye is least sensitive to first. Smooth gradients (skies, skin tones, shadows) show blocky artifacts at much higher quality settings than sharp, high-contrast edges (text, hard object outlines), which tend to survive fairly low quality settings before looking obviously bad. That's why two photos compressed at the identical quality number can look very different: a sunset with a smooth sky gradient will show compression artifacts sooner than a high-contrast product photo on a plain background.
As a starting point: quality 0.8–0.9 combined with a sensible resize (1600–2000px for most web/email uses) keeps compression artifacts below the threshold most people notice on a normal screen, while still cutting file size by 60% or more versus an unmodified phone photo. Push below roughly 0.5 and artifacts usually become noticeable, especially on skies, skin tones, and other smooth-gradient areas — useful when file size matters more than polish, but not "no visible loss" territory anymore.
At an equivalent visual quality, WebP generally produces a smaller file than JPG — it's a newer codec built specifically to be more efficient. If the destination (a website, an upload form, an app) explicitly supports WebP, it's usually the better default. PNG is true lossless — no quality slider needed, no visible loss ever — but produces much larger files for photographs; it's the right choice for screenshots, diagrams, or anything needing transparency, not for compressing an actual photo down for size.
Re-compressing an already-compressed JPG doesn't meaningfully shrink it further — most of the easy savings were already taken the first time — but it does add another round of quality loss on top of the first. If a photo needs re-compressing (a different quality target, a different max dimension), always start from the original file, not from a previously compressed copy, or the visible quality loss compounds for no real size benefit.
All of the above — the resize, the format conversion, the quality re-encode — happens locally on an in-browser <canvas> in the Compress Image tool. No file-size limit is enforced from an upload quota (there is no upload), and a whole batch of photos can be compressed and downloaded together as one ZIP.
What's the single best setting for "no visible loss"? There isn't one universal number — it depends on the photo's content and viewing size — but 0.85–0.9 quality with dimensions capped to roughly what will actually be displayed is a reliable starting point for most photos.
Is PNG always safer than JPG for quality? Pixel-for-pixel, yes — PNG is lossless. But for an actual photograph (as opposed to a graphic or screenshot), PNG's file size is often several times larger than a well-tuned JPG or WebP at a quality setting most people can't tell apart from lossless.
Does resizing count as "losing quality"? Not in the way people usually mean — it reduces resolution, which is a size vs. detail tradeoff, not the blocky, gradient-banding kind of "quality loss" that comes from aggressive lossy re-encoding at full resolution.