How to Compress Images for the Web Without Losing Quality

Images are the heaviest thing on most web pages — routinely half the bytes a visitor downloads. The good news is that the gap between a straight-off-the-camera image and a well-prepared one is enormous: a 4 MB photo can almost always become a 150 KB one that looks identical on the page. Getting there is a three-step discipline: resize, choose a format, then compress. Most people skip straight to step three and leave the biggest win on the table.

Step 1: resize first — the biggest win by far

A modern phone shoots at 4000×3000 pixels. If your page displays that image 800 pixels wide, you’re shipping roughly 14× more pixels than anyone can see — the browser downloads all twelve million of them, then throws most away while scaling down. No quality slider can compete with simply not sending those pixels. Run the image through the Image Resizer to its real display width (a common rule: 2× the CSS width to stay sharp on retina screens, so 1600px for an 800px slot). This one step often cuts file size by 80–90% before any compression happens.

Step 2: pick the right format

Photographs belong in JPEG or WebP; screenshots, logos and diagrams belong in PNG. Getting this wrong either bloats the file or smears the image, and the full reasoning is in our PNG vs JPEG vs WebP guide. For images your own site serves, WebP is the modern default — it delivers the same visual quality as JPEG in files roughly a quarter to a third smaller.

Step 3: compress — and where the quality sweet spot is

Lossy encoders take a quality setting from 0–100, and the relationship to file size is dramatically non-linear. Quality 100 files are huge for no visible benefit; 80–85 is the sweet spot where files shrink to a fraction of their original size while remaining visually indistinguishable at normal viewing distance. Below ~70, artifacts start creeping into gradients and fine texture; by 50 they’re obvious. When is lower justified? Backgrounds behind text overlays, thumbnails, and images that are decorative rather than content can go to 60–70 without anyone caring. The Image Compressor shows a live before/after comparison as you move the slider, so you can find the exact point where your image starts to degrade instead of trusting a universal number.

What “lossless” really means

“Compress without losing quality” hides an ambiguity. Lossless compression (PNG, WebP-lossless) restores every pixel exactly — nothing is lost, but savings on photos are modest. Lossy compression discards information permanently — but discards it from the parts of the signal human vision barely registers. So the honest phrasing is: lossy at quality 80–85 loses data without losing visible quality. Two corollaries follow. Keep your original as the master, because you can’t un-compress. And never re-save a JPEG as JPEG repeatedly — each generation stacks new losses on old ones, which is why editing workflows keep a PNG or RAW original and export lossy only once, at the end.

Why page speed cares: Core Web Vitals and LCP

Google’s Core Web Vitals make this concrete. Largest Contentful Paint (LCP) measures how long the biggest element in the viewport — very often a hero image — takes to appear, and Google’s threshold for “good” is 2.5 seconds. A 3 MB hero image can spend that entire budget just downloading on a median mobile connection; the same image prepared properly loads in a few hundred milliseconds. Since Core Web Vitals feed into search ranking and oversized images are the single most common LCP culprit, image compression is one of the rare optimizations that is simultaneously trivial and high-impact.

The practical workflow

  1. Decide the largest size the image will actually display at, double it for retina, and resize to that in the Image Resizer.
  2. Export as WebP (or JPEG if the destination can’t take WebP).
  3. Open the result in the Image Compressor, start at quality 82, and nudge down until you see degradation — then step back up one notch.
  4. Keep the original file somewhere safe as the master.

Both tools run entirely in your browser — the images never upload to a server, so the workflow is as fast for fifty photos as for one and works fine on files you’d rather not send anywhere.

An honest note on PNG optimization

One limit worth stating plainly: browser canvas–based tools excel at lossy JPEG and WebP compression, but heavy PNG optimization is a different craft. The big PNG wins come from palette quantization — reducing an image to 256 or fewer carefully chosen colors — plus exhaustive filter search, which is the territory of dedicated tools like pngquant, OxiPNG or Squoosh’s codecs. If a PNG screenshot must get radically smaller, use one of those; or ask whether the image is really PNG-shaped content at all — converting a photo mistakenly saved as PNG to WebP saves more than any optimizer will.