How to Compress Images for the Web Without Visible Quality Loss

“No visible loss” depends on context

Lossy compression always changes pixel data. The useful goal is perceptual: changes should not be objectionable at the intended display size, density, and viewing conditions. A quality setting that works for a soft photograph may damage text, line art, gradients, or synthetic graphics.

Evaluate the actual asset rather than relying on a universal quality number. Encoder scales are not standardised, and a browser or content platform may perform another encode after upload.

• Inspect at normal display size first, then use 100% zoom to diagnose artefacts.
• Look closely at edges, faces, fine texture, shadows, gradients, and saturated colours.
• Compare against the source on the same colour-managed display when colour is important.

Remove unnecessary pixels before tuning quality

An image delivered much larger than its rendered slot wastes transfer bytes and decode work. Produce width variants that match real layout needs, then use srcset and sizes so the browser can choose. Keep a larger source outside the delivery folder for future layouts.

High-density screens can benefit from more source pixels, but automatically sending the largest file to every device is not the answer. Test the point where extra pixels stop making a meaningful visual difference.

• Measure rendered widths at representative breakpoints.
• Preserve aspect ratio unless a deliberate crop is part of the design.
• Set width and height attributes to reduce layout movement.
• Do not upscale a small source and call it optimised; interpolation cannot restore absent detail.

Pick a format, then tune the encoder

Use JPG, WebP, or AVIF candidates for photographic material and compare them. For screenshots, flat graphics, and transparency, compare PNG with lossless or carefully tuned modern formats. Format conversion and compression should be judged together because the best setting depends on the codec.

• Start from the original, not from an already compressed derivative.
• Make several candidates around a sensible quality range and choose the smallest acceptable result.
• Strip nonessential metadata for delivery, but preserve rights or colour information when required.
• Keep a compatible fallback when a target browser, crawler, editor, or email client cannot decode the preferred format.

Validate in the page, not only in a file viewer

Place the candidate in the real component and test narrow and wide viewports, light and dark backgrounds, and high-density displays. Use browser developer tools to confirm which source was downloaded and whether a supposedly lazy image is still fetched early.

Optimisation can harm experience when it makes an important image blurry, delays encoding in a request path, or breaks a crawler. Treat visual review, accessibility, compatibility, and performance measurements as one release check.

• Prioritise the likely largest visible image; do not lazy-load an above-the-fold hero without testing the impact.
• Lazy-load suitable off-screen images and provide meaningful alt text.
• Cache immutable derivatives with versioned URLs.
• Re-test representative pages after changing a global image pipeline.