How to Compress Images Without Losing Quality

Start at around 80% quality and look at the before/after slider at full size. Slowly lower the value and watch the areas most likely to break first: smooth gradients such as skies, fine textures, and hard edges near text. The moment you see faint blockiness or blur appear, step back up a few points. That threshold is the smallest file that still looks identical — and it differs from image to image, which is why previewing beats a fixed number.

Judge at 100% zoom rather than fitted to the window, because a shrunk preview hides exactly the artifacts you are hunting for. Compare on the places that fail first — a face near the edge of the frame, a gradient sky, the shadow under a chin, a logo in the corner — instead of on busy texture, which conceals damage well. And treat the number as untransferable: a photo of a foggy lake may hold up at quality 60, while a product shot on a white background can need 88 before the edges stop shimmering.

The single biggest win is usually dimensions, not quality. A phone photo can be 4000 pixels wide, but a blog body image rarely needs more than about 1600 pixels, and a thumbnail far less. Halving an image's width and height removes three-quarters of its pixels before compression even begins. Set a sensible maximum width or height for where the image will actually be shown, and you often cut the file size more than any quality slider can — with zero visible loss at display size.

Do the arithmetic once and the habit sticks. A 4032×3024 phone photo is 12.2 megapixels; capped at 1600 pixels wide it becomes 1.9 megapixels, about a sixth of the data. The browser does not thank you for the extra pixels either: it decodes the whole image into memory at roughly four bytes per pixel, so that original costs close to 49 MB of RAM on the device before most of it is discarded to paint an 800-pixel-wide slot.

Send photographs to JPEG or WebP and graphics to PNG or lossless WebP; the wrong format wastes bytes no quality setting can recover. Then compress from the original file rather than from an already-compressed copy, so you avoid generational loss. Do these three things — right dimensions, right format, one careful pass — and a typical web image drops 60–80% in size while remaining, to the eye, exactly the same.

A camera file carries more than pixels. EXIF and XMP metadata plus an embedded preview thumbnail commonly add 20–60 KB, and a colour profile can range from a few hundred bytes for sRGB to several hundred kilobytes for a large camera profile. On a 60 KB thumbnail that payload can outweigh the picture itself. Re-encoding removes it, which for web delivery is usually exactly what you want.

Colour is the one thing to be careful about. If the original is in a wide gamut such as Display P3 or Adobe RGB and you drop the profile without converting, browsers read the numbers as sRGB and the picture comes back flat or oversaturated. Convert to sRGB first, or keep the profile — just do not silently delete it from a wide-gamut file.

Put the steps in this order and you rarely have to redo anything. Start from the largest original you have, never from a file that has already been through a lossy encoder. Crop and edit first, while the data is intact. Resize to the maximum dimension the layout actually needs. Choose the format from the content rather than from habit. Only then lower the quality, watching the preview. Export, and keep the original untouched for the next time the design changes.

It is also worth knowing when to stop. Below roughly 30 KB the fixed overhead of the container and whatever metadata remains starts to dominate, and further quality cuts buy a kilobyte or two at a visible cost. At that point the remaining wins come from elsewhere: serving a smaller variant to small screens, or not loading the image at all until the reader scrolls near it.