How to compress images without losing quality

“Without losing quality” is technically a lie — every lossy compressor loses something. The real question is whether you can tell. With the right format, the right dimensions, and a reasonable quality setting, you can cut a 4MB photo to 200KB and no one — not even you — will see the difference. This guide is the short version of what actually moves the needle, and what doesn’t.

The three quality levers

Every image compression decision is really three decisions, and most people only touch one. The levers are format (JPG, PNG, WebP, AVIF), dimensions (pixel width and height), and compression quality (the 0-100 slider). Pull all three and the file gets dramatically smaller. Pull only the slider and you’re leaving most of the savings on the table.

When JPG beats PNG

JPG is for photographs — anything with continuous tones, skin, sky, landscapes. PNG is for anything with sharp edges and flat color: logos, icons, screenshots of UI, text. Save a photo as PNG and you’ll end up with a 4MB file that a 300KB JPG would match visually. Save a logo as JPG and you’ll get ugly compression halos around the edges.

Rough rule: if the image has a camera in its history, it’s a JPG. If it came out of Figma, Illustrator, or a screenshot, it’s a PNG.

When WebP and AVIF win

WebP is usually 25-35% smaller than JPG at the same visual quality, and supports transparency like PNG. AVIF goes further — often 50% smaller than JPG — but encoders are slower and ancient software doesn’t understand it. For a modern website or a blog image, WebP is the default answer. AVIF if you control the whole stack and care about the last 20% of savings.

For anything leaving your site — email, Slack, a print shop, iMessage — stay in JPG or PNG. The recipient’s tool chain may or may not handle the newer formats.

Resize before you compress

This is the move that gets skipped most often and saves the most bytes. A photo straight off a phone is 4032×3024 pixels. A blog hero image displays at maybe 1600px wide. Shipping the phone resolution to a browser is a 6x waste. Resize first with an image resizer, then run the result through an image compressor. Compression after resizing is vastly more effective than compression alone.

Acceptable file sizes in the wild

Rough targets, after both resizing and compression:

• Blog hero image (1600px wide): 150-300KB. Over 500KB and your page speed score will notice.
• Product photo (1200px wide): 80-180KB per image. You probably have a dozen on the page, so every kilobyte compounds.
• Email attachment photo (1600px wide, decent quality): 200-400KB. Under that and it starts looking compressed on larger screens.
• Social upload: the platform will recompress anyway, so there’s no point shipping more than 2MB in.

Testing with a quality slider

The honest way to pick a quality setting: export at 90, 80, and 70, open all three side by side at 100% zoom, and pick the lowest number where you genuinely can’t tell the difference from the original. For most photos, that’s 80-85. For screenshots with text, stay at 90+ or you’ll see fringing on letters. Don’t trust your memory — open them side by side.

What doesn’t help

Running a file through two compressors in a row does nothing good — you just compound artifacts. Saving a JPG as JPG repeatedly (opening, editing, re-saving) degrades it every time; keep a PNG or RAW master if you’re going to edit. And obsessing over the last 5KB on a file that’s already under 200KB is almost never worth it.