How to Compress Images for the Web
Images are the heaviest thing on most web pages, routinely half the bytes a visitor downloads. The gap between a straight-off-the-camera file and a well-prepared one is also enormous: a 4 MB photo can almost always become a 150 KB one that looks identical on the page. Getting there takes three steps in order, which are resize, choose a format, then compress. Most people skip straight to the third and leave the biggest win untouched.
Step 1: resize, which is where the real saving is
A modern phone shoots at 4000×3000 pixels. If your page displays that image 800 pixels wide, you are shipping roughly 14 times more pixels than anyone can see. The browser downloads all twelve million of them and then throws most away while scaling down. No quality slider competes with simply not sending those pixels in the first place.
Run the image through the Image Resizer at its real display width. A common rule is double the CSS width to stay sharp on retina screens, so 1600px for an 800px slot. This one step often cuts file size by 80 to 90% before any compression happens at all.
Step 2: pick the right format
Photographs belong in JPEG or WebP; screenshots, logos and diagrams belong in PNG. Getting this backwards either bloats the file or smears the image.
The full reasoning lives in our PNG vs JPEG vs WebP guide. For images your own site serves, WebP is the modern default, delivering the same visual quality as JPEG in files roughly a quarter to a third smaller.
Step 3: compress, and find the quality sweet spot
Lossy encoders take a quality setting from 0 to 100, and its relationship to file size is dramatically non-linear. Quality 100 files are huge for no visible benefit. Somewhere around 80 to 85 is the sweet spot, where files shrink to a fraction of their original size and stay indistinguishable at normal viewing distance. Below about 70, artifacts start creeping into gradients and fine texture. By 50 they are obvious.
Lower settings do have their place: backgrounds behind text overlays, thumbnails and purely decorative images can drop to 60 or 70 without anyone caring. The Image Compressor shows a live before and after as you move the slider, so you can find the point where your image starts to fall apart instead of trusting a universal number.
What “lossless” really means
“Compress without losing quality” hides an ambiguity worth naming. Lossless compression (PNG, WebP-lossless) restores every pixel exactly, so nothing is lost, but the savings on photos are modest. Lossy compression discards information permanently, and discards it from the parts of the signal human vision barely registers. What actually happens at quality 80 to 85 is that data is lost without visible quality loss, which is not the same claim.
Two things follow. Keep your original as the master, because you cannot un-compress. And never re-save a JPEG as a JPEG over and over, since each generation stacks new losses on top of old ones. That is why editing workflows hold on to a PNG or RAW original and export lossy exactly once, at the end.
Why page speed cares: Core Web Vitals and LCP
Google’s Core Web Vitals make all of this concrete. Largest Contentful Paint measures how long the biggest element in the viewport takes to appear, which is very often a hero image, and Google’s threshold for “good” is 2.5 seconds. A 3 MB hero can spend that entire budget just downloading on a median mobile connection, while the same image prepared properly loads in a few hundred milliseconds.
Core Web Vitals feed into search ranking, and oversized images are the single most common LCP culprit. This is one of the rare optimizations that is both trivial to do and worth a lot.
The practical workflow
- Decide the largest size the image will actually display at, double it for retina, and resize to that in the Image Resizer.
- Export as WebP, or JPEG if the destination can’t take WebP.
- Open the result in the Image Compressor, start at quality 82, and nudge down until you see degradation, then step back up one notch.
- Keep the original file somewhere safe as the master.
Both tools run in the browser rather than handing your images to a processing server, so the workflow is as fast for fifty photos as for one, and it still works on files you would rather not send anywhere.
Where browser tools stop being the right answer
One limit is worth stating plainly. Canvas-based tools in a browser excel at lossy JPEG and WebP compression, but heavy PNG optimization is a different craft. The big PNG wins come from palette quantization, which reduces an image to 256 or fewer carefully chosen colors, plus exhaustive filter search. That is the territory of dedicated tools like pngquant, OxiPNG or Squoosh’s codecs.
So if a PNG screenshot has to get radically smaller, reach for one of those. Or ask whether the image is PNG-shaped content at all: converting a photo that was mistakenly saved as PNG over to WebP saves more than any optimizer will.