Every online image compressor makes the same claim: "reduce file size without losing quality". That claim is technically nonsense — any lossy compression involves some information loss by definition. What people actually mean when they say "without losing quality" is "without visible quality loss to a normal human looking at the image at typical viewing distance and size". That's a real thing, and it's achievable. But knowing where the invisible-loss threshold sits, and how to stay above it, requires understanding what the compressor is actually doing to your file.
This piece walks through the practical settings on JPEG, WebP, PNG and AVIF that hit the "smaller file, no visible change" target, and the situations where you have to trade some fidelity for size on purpose. All the numbers here are from thousands of test compressions across the tool, cross-referenced with the primary literature on human perceptual quality (SSIM, VMAF, Butteraugli).
The one setting that matters most: quality
Every lossy image format (JPEG, WebP, AVIF, HEIC) has a quality parameter, usually expressed 0–100. That number is not a percentage of the original quality and is not directly comparable between formats. What it controls is how aggressively the encoder discards perceptual information — specifically, how coarsely it quantises the frequency-domain representation of each 8×8 or 16×16 block of the image.
The important thresholds in practice:
- Quality 95–100 is essentially lossless perceptually. Files are large. Use only when you need to preserve every detail (medical, forensic, print masters). Wasted bytes for the web.
- Quality 85–90 is the "invisible loss" band for typical photography. Almost nobody can tell an image at this quality from the original at normal viewing distance. Files are 40–60% of the size of quality 95. This is the right default for editorial photography, product photography, portfolio work.
- Quality 75–85 is the "invisible loss on most content, subtle loss on some" band. Photos of nature, food, portraits, and product shots almost never show visible degradation. Content with large flat regions (sky, skin, painted walls) can start to show subtle blocking artefacts. Files are typically 20–30% the size of quality 95. Right default for web images generally.
- Quality 60–75 is where visible loss appears on some content. Skies show banding, edges show ringing. Right for thumbnails and non-hero content where file size dominates. Files are typically 10–20% the size of quality 95.
- Quality below 60 is visibly degraded on nearly all content. Right for extreme cases only (thumbnails at ≤ 100 px, form-upload compression to hit hard KB targets).
The single most useful default in the entire toolkit is quality 82. That value sits precisely in the sweet spot where 99% of content still looks identical to the original but the file is a quarter of the size of the max-quality version. It is what the tool ships as the default for a reason.
The second setting that matters: dimensions
Compressing an image at 4000 px wide and then serving it in a 600 px slot on a mobile page is not compression, it is waste. The browser downloads all the extra pixels and throws them away at render time. The single most impactful thing you can do for file size on the web is resize the image to the dimensions it will actually render at (times a retina factor of 2, if you care about retina).
Order matters. Resize first, then compress. Compressing a 4000 px image and then downscaling the result to 800 px does two rounds of information loss — one from the compression at 4000 px, one from the downsampling. Downscaling first to 800 px and then compressing does one round. The perceptual difference is small but consistent.
Sensible defaults for common use cases: 1200 px for retina blog inline images (render at 600 px), 1600 px for retina product page mains (render at 800 px), 2400 px for retina desktop heroes (render at 1200 px), 400 px for retina thumbnails (render at 200 px).
Format selection matters more than quality tuning
Switching format is often a bigger win than any amount of quality-slider fiddling. JPEG at quality 85 is roughly the same file size as WebP at quality 75 at the same visible quality — because WebP's encoder is more efficient. Going from JPEG to WebP at equivalent visible quality saves 25–35% on typical photos. Going from WebP to AVIF at equivalent visible quality saves another 15–25%.
For different content types the format hierarchy differs. Photography: AVIF > WebP > JPEG > PNG (in descending file-size efficiency). Screenshots and UI: PNG (lossless) or WebP lossless mode for perfect reproduction; WebP lossy for smaller files with acceptable degradation. Graphics with transparency: WebP or PNG. Vector graphics: SVG (never rasterise for the web unless you have to).
The one gotcha is transparency. JPEG has no alpha channel; converting a PNG-with-transparency to JPEG flattens the transparency to a solid background colour (usually white). If your image needs to sit on top of a coloured background, you need PNG, WebP or AVIF.
Chroma subsampling and the "smoother" trick
JPEG has a technique called chroma subsampling that saves 30–40% on file size by encoding colour information at lower resolution than brightness information. Human eyes are much more sensitive to brightness than to colour, so 4:2:0 chroma subsampling (the standard "small file" setting) is invisible on photography but visibly softens edges on line art, screenshots and text.
The rule of thumb: for photographic content, always use 4:2:0 subsampling (this is what quality 80 or below typically forces by default). For anything with sharp edges — text overlays, graphics, screenshots — use 4:4:4 subsampling (typically triggered by quality 90+ in libjpeg) or switch to a lossless format entirely.
Progressive JPEG for web delivery
A progressive JPEG loads in multiple passes — first a low-quality version of the entire image, then successive refinement passes. A baseline JPEG loads top-to-bottom. For the same visual quality and file size, progressive JPEGs produce a much better perceived-load experience because the reader sees a rough version of the whole image within the first 20% of the download.
The tool ships progressive-JPEG output by default for that reason. There is no downside — modern browsers all handle progressive rendering, and the file is often 2–5% smaller than baseline. If you're using a photo processing tool that offers "baseline vs progressive", always pick progressive for the web.
What "no visible loss" actually measures
The formal measure of perceptual image quality is SSIM (Structural Similarity Index) or its improved siblings MS-SSIM, VMAF and Butteraugli. An SSIM of 1.0 is a pixel-perfect copy; 0.99 is imperceptible from the original; 0.95 has subtle loss visible to a trained eye; 0.90 has clear loss visible to anyone. Most "high quality" web JPEGs are 0.97–0.99 SSIM against the original. Below 0.95 you are trading fidelity for file size on purpose.
In practical terms: if you compress an image and can't see any difference on a blind side-by-side comparison in your target viewing environment, the compression is invisible for that context. The blind-comparison test is the only test that matters — synthetic quality metrics correlate with human perception but don't replace it.
Practical workflow
The most reliable "compress without visible loss" workflow: (1) resize to the largest dimension you will actually display at, times 2 for retina; (2) pick the smallest-file format your target browsers support universally (WebP for 2026, or AVIF if you have the encode budget); (3) compress at quality 82 as the default, quality 88 for editorial or portfolio content where every detail matters, quality 75 for below-the-fold thumbnails; (4) preview the result at actual display size and confirm you can't see the difference; (5) ship.
The compressor on this site ships with these defaults exactly. You can adjust the quality slider and see the before/after side-by-side in the browser, on your own file, in about ten seconds. That is worth more than any general guidance — the "invisible loss" threshold shifts with content type, and testing on your own material is faster than reading another article.