How to Compress Images Without Losing Quality (Practical Guide)

“Compress images without losing quality” is technically a contradiction. Compression always involves a trade-off. Either you discard information (lossy) or you find a more efficient way to encode the same information (lossless). What people usually mean is “without losing visible quality,” and that’s an entirely realistic goal.

Below are the techniques we reach for in our own work, in priority order from highest impact to lowest. If you only have an hour to spend on image optimization, the top two are where to spend it.

1. Pick the right format first

Format choice is the biggest single lever you have. Compressing a 4 MB photograph as PNG and then “optimizing” the PNG might save you 20%. Re-saving the same photo as JPEG quality 80 saves 90% with no visible difference. The format matters more than the encoder.

Quick rules:

For photographs, pick JPG, WebP, or AVIF.
For screenshots, icons, and UI graphics, stick with PNG (or WebP lossless if you want smaller files).
Anything with transparency rules out JPG. PNG, WebP, or AVIF are the options.
For vector content, SVG when you still have the source.

Publishing a photograph as PNG means you’ve already lost the most important compression battle before you ever touch a slider.

2. Resize to display size

The fastest way to shrink an image is to make it smaller, full stop. A 4000-pixel-wide photo displayed at 800 px is wasting roughly 96% of its bytes. Most of those pixels are being thrown away by the browser’s own downsampling before anyone sees them.

Practical dimensions we use day-to-day:

Hero images should match your largest viewport. For a max-width 1200 px container on a Retina display, render at 2400 px. More than that is waste.
Article body images rarely need to exceed 1200–1600 px.
Thumbnails cap out at 400–600 px.
Avatars and small UI elements, 200 px or less.

Responsive images via srcset let you ship the right resolution to each device. If you don’t have that infrastructure yet, pick the smallest size that still looks crisp on a Retina display in your largest container and call it done.

3. Pick the right quality setting

For lossy formats (JPG, WebP, AVIF), the quality parameter is your main lever. Despite what the slider implies, quality 100 is almost never necessary:

Format	“Sweet spot”	Aggressive	Visually-lossless
JPG	75–80	60–65	90–95
WebP	75–85	60–70	90–95
AVIF	55–65	40–50	75–85

The “visually lossless” column is what most people actually mean when they say “without losing quality.” At those settings you’d need to zoom in and look at fine details to spot the difference. For everyday web delivery, the sweet-spot column is the right answer and we rarely push it higher than that for photographs.

4. Strip metadata you don’t need

Photos straight out of a camera or phone usually carry:

EXIF data: camera model, ISO, shutter speed, GPS coordinates, capture date.
Embedded color profiles, which on their own can run to hundreds of KB.
Thumbnail previews baked into the file.
XMP and IPTC metadata for editorial workflows.

Almost none of this matters for web delivery. A routine metadata strip shaves anywhere from 5 to 50 KB off each image with zero visible change, and the GPS removal is a quiet privacy improvement too — worth doing before you publish anyone’s phone photos to the public web.

Most online compressors, ours included, strip non-essential metadata automatically.

5. Compress with a real tool, not your editor’s “Save for Web”

Image editors like Photoshop and Affinity have built-in export options (“Save for Web”, “Export As”) that do a reasonable job. But dedicated compressors consistently produce smaller files at the same visual quality. The ones we still reach for:

For PNG: pngquant for lossy (50–80% savings on typical UI screenshots), or oxipng / zopflipng for true bit-identical lossless (5–30% savings).
For JPG: mozjpeg, a drop-in replacement that produces smaller files than libjpeg with the same quality.
For WebP: cwebp, the official Google encoder.
For AVIF: avifenc or cavif.

Or wrap those encoders in an online tool. Our PNG compressor and JPG compressor both run entirely in your browser using the platform’s native encoders. No upload, no signup.

6. Consider the right color depth

A surprising number of PNGs use 32 bits per pixel when they could comfortably fit in 8. If your image has transparency but only a handful of solid colors — think a two-color logo on a transparent background — converting to a palette PNG (PNG-8) can shrink the file by a factor of four with no perceptible difference.

Almost no one thinks about this manually. pngquant handles it automatically by analyzing the image and converting to a palette when it’s safe.

7. For photos: trust your eyes, not the file size

When tuning quality settings, the temptation is to look at the file size and think “smaller is better.” That’s only true up to the point where artifacts become visible.

A workable workflow:

Compress at quality 90.
Compare side-by-side with the original at 100% zoom on the actual device you’ll display it on.
If you can’t tell the difference, drop to quality 80.
Repeat. When you start to see artifacts, back up one step.

For most photos, the threshold sits around quality 75–80 for JPG, 75–85 for WebP, and 55–65 for AVIF. Anything below that begins to show ringing around edges and banding in gradients.

8. Use responsive images with `srcset`

Even after compressing, a single large image is wasteful when most users are on phones. Modern HTML lets you ship multiple sizes:

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  alt="..."
  width="800"
  height="450"
  loading="lazy"
>

The browser picks the right size based on the viewport. A user on a 375-pixel iPhone never downloads the 1600-pixel version.

9. Combine formats with `<picture>`

Building on srcset, the <picture> element lets you offer multiple formats too:

<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" alt="..." width="800" height="450" loading="lazy">
</picture>

This serves AVIF to modern Chrome, WebP to Safari 14, and JPG to ancient browsers. Three formats, one HTML element.

10. Don’t over-engineer for tiny images

Spending an hour to shrink a 2 KB icon to 1.6 KB is a waste of your time. The optimization effort has to go to the assets that actually move the needle: your hero images, above-the-fold photos, and anything that appears on every page.

The Pareto rule we follow: focus your first hour on the biggest five images across your top five pages. That alone usually captures 80% of what’s available.

Common mistakes

A few anti-patterns we keep running into on client sites:

Re-saving JPGs repeatedly. JPG is lossy. Every re-encode degrades the image a little more, even at quality 95. Keep your masters in PNG, TIFF, or your editor’s native format and only export JPG at the final step.
“Compressing” already-compressed files. Once an image has been through a good compressor, further passes give you almost nothing. Don’t expect a 50% saving from a file that’s already been to the gym.
Trusting file extensions blindly. A file named photo.jpg could be anything. Check the actual format before you feed it to an optimizer.
Optimizing without measuring. Use Lighthouse or PageSpeed Insights to measure Core Web Vitals. The number that matters is LCP, not raw file size in isolation.

The bottom line

You can shrink image file sizes by 70–90% with no perceptible quality change. It just takes a series of small, mostly mechanical decisions:

Pick the right format for the content type.
Resize to actual display dimensions.
Pick a quality setting in the sweet spot for your format.
Strip metadata.
Use a real compressor, not just your editor’s export.
Ship responsive images with srcset and <picture>.

Do all six and your Core Web Vitals will reflect it within a week of Google’s next crawl.

Want to start now? Our PNG to WebP converter, PNG compressor, and JPG compressor all run in your browser, with no uploads or limits.