How to Compress Images Without Losing Quality

Why a large reduction does not mean a visible loss

Lossy compression, the kind JPG and WebP use, is built around how human vision actually works rather than around preserving every byte equally. It discards colour information more aggressively than brightness information, since the eye is far more sensitive to changes in brightness than to subtle colour shifts, and it compresses smooth, gradual areas more than it compresses sharp edges and fine texture, since smooth areas have far less information the eye would miss anyway. A photo that is mostly sky, skin, or an out of focus background, exactly the kind of content a real photo usually has plenty of, compresses extremely well under this approach with nothing visibly lost.

Where the line actually is

Quality 80 and above rarely shows any visible loss on a typical photo viewed at normal size. Quality 50 to 60 usually still looks fine for a thumbnail, a preview, or anything not being viewed large or zoomed in closely, though a very close look can start to reveal it. Below about quality 40, compression artefacts become genuinely visible: soft blocky patches in smooth areas like sky or skin, and a slight fuzziness around sharp edges and fine detail. Where exactly visible loss starts depends on the specific image, a simple, low detail photo tolerates a lower quality setting than a busy, highly detailed one before the difference becomes noticeable.

One image at three quality settings

To see those lines on a real run, we put one test image through the JPG Compressor in Google Chrome 157 on 8 November 2026. The image is a 2400 x 1600 scene that a script drew, with a sky gradient, a sun, two hills, a fine line grid and light noise, saved as a JPG at quality 92 and 878 KB in size. It is a generated image, not a photograph, so a real photo will give different sizes. Sizes below are kilobytes of 1,024 bytes, as the tool counts them.

We then looked at each result at 300 percent zoom beside the original. At 80, the only change was that the fine noise had been smoothed, and the edges stayed clean. At 50, the grain was nearly gone and a faint dark fringe ran along the edge of the hill. At 20, the sky had broken into visible blocks and the hill edge stepped. Those are close-up differences, and the file sizes show the price of each step: going from 80 to 50 removed about 204 KB, while going from 50 to 20 removed only about 78 KB more, and that second step is where the blocks appeared. At quality 95 the tool handed back the original file, marked already optimized, because re-encoding it was not smaller.

How to actually tell, on a specific image

The most reliable test is a direct side by side comparison at the actual size the image will be viewed at, not zoomed in past that size, since zooming in reveals differences no viewer will ever actually see at normal size. A compare slider that shows the original and the compressed result side by side, sliding between them at the same size, makes a real difference obvious if one exists and reassuring if it does not, which is more reliable than trying to judge a single image in isolation against memory of what the original looked like.

Quality mode or a target size, and why it changes the approach

Quality mode is the right choice when the goal is simply a smaller file with no visible change, drag the slider, check the compare view, stop once it looks right. Target size mode flips the priority: something external sets a hard limit, a 100 KB upload form or a 1 MB email attachment cap, and the tool searches for the highest quality that still fits under that number rather than you picking a quality and hoping the resulting size happens to work. Both use the same underlying compression; the difference is just which variable you are solving for.

Format changes the ceiling, not just the number

A JPG and a WebP at the same quality number do not produce the same visual result or the same file size, since the two formats compress differently under the hood; WebP at an equivalent visual quality generally produces a smaller file than JPG. This means the format choice sets the ceiling on how small a file can get before quality visibly drops, before the quality slider itself even comes into play. If a JPG cannot reach a target size cleanly, converting to WebP first, then compressing, sometimes reaches the same target at a noticeably higher visual quality than pushing the JPG's own quality setting lower would have.

PNG is a different kind of compression entirely

Everything above describes lossy compression, JPG and WebP's approach of discarding detail. PNG compresses losslessly instead, by reducing the number of distinct colours in the image rather than by discarding detail, which works well for flat graphics with few colours to begin with and works poorly for a photograph's thousands of subtle shades. A PNG that will not compress much no matter what quality setting is tried is usually a sign the source is a photo, not that the compressor is failing; converting to JPG or WebP first is the actual fix in that case, not pushing the PNG compressor harder.

Resizing first often beats compressing harder

If a file still needs to shrink further after quality alone has been pushed as low as looks acceptable, reducing the pixel dimensions usually gets further than pushing quality lower still. A smaller image needs fewer pixels' worth of data regardless of quality setting, and a modest resize, say to three quarters or half the original width, often produces a smaller, cleaner looking result than the same target size reached purely through a very aggressive quality setting on the full size image. This matters most when the image will never actually be displayed at its original full resolution anyway, which describes most photos destined for a screen rather than a large print.

Compressing a whole batch consistently

Picking a quality setting on one representative image from a batch, checking it against the compare view, then applying that same setting to the rest of the batch produces more consistent results than eyeballing every single image individually, and it is much faster for a batch of any real size. A batch of similar images, photos from the same shoot or the same camera, usually compresses consistently well at the same quality setting, since they share similar levels of detail and similar content.

What the quality slider does to a PNG

On a JPG or WebP the quality number decides how much fine detail the encoder throws away. On a PNG it decides something else: how many colors the file may keep. In Imagenati's compressors, quality 80 allows up to 128 colors, 60 allows 64 and 40 allows 32, while 100 leaves the PNG lossless. An image that already has fewer colors than the limit, such as a simple logo, is stored exactly. Otherwise the tool compares the reduced PNG with the original and keeps the lossless version if the colors have shifted too far or the reduced file is not smaller.

Reading the labels in the results table

A plain percentage in a row is the saving. A label saying the file is larger by some percentage means the chosen settings produced a heavier file, which happens when a small, heavily compressed JPG is saved again at a higher quality, or when a photo is converted to PNG. If the format stays the same, no resize is set and the new encode would not come out smaller, the compressor keeps the original encoding, strips the location and camera metadata from it, and marks the row as already optimized. In target size mode, a note that the target was not reached means the download is the smallest version the tool tried, and it is still over your limit.

Habits that cost quality for nothing

• Saving the same JPG again and again. Every lossy save discards a little more, so compress once, from the least compressed copy you have.
• Compressing first and editing afterward. Crop, resize and rotate the image, then compress the finished version as the last step.
• Replacing the only original. Keep the original until the smaller file has been checked where it will be used.