How to Compress Images for the Web Without Losing Visible Quality

A practical guide to shrinking JPG, PNG, and WebP files for the web - which format to use, what the quality slider actually does, and how to tell when you have gone too far.

Most slow pages are slow because of images. Not JavaScript, not fonts - images. A single photo straight off a phone can outweigh every other asset on the page combined, and there are usually a dozen of them.

The fix is compression, and the reason people avoid it is that they have been burned once. They ran a photo through something, the result looked blotchy, and they went back to uploading originals. That is a reasonable reaction to a bad default, but it is the wrong lesson. Done properly, you can cut a typical photo by 70 to 80 percent and be unable to pick the compressed version out of a lineup.

Here is how to do that reliably.

Start by understanding what you are trading

Image compression comes in two kinds, and mixing them up is the root of most bad results.

Lossy compression throws information away permanently. JPEG and lossy WebP work by discarding detail your eye is bad at noticing - subtle color variation, fine texture in busy areas - and keeping the detail it is good at noticing, like edges and contrast. The "quality" number you set is really a question about how much it is allowed to discard.

Lossless compression throws nothing away. It just stores the same pixels more efficiently, the way a ZIP file does. PNG is lossless. Run a PNG through a lossless optimizer and you get a smaller file that is bit-for-bit identical when decoded.

The practical consequence: lossy compression is repeatable damage. Every time you re-encode a JPEG, you compress the artifacts from the last pass along with the image. Always compress from the original, never from a copy you already compressed.

Pick the format before you pick the number

Format choice moves the needle far more than quality settings do.

• Photographs belong in WebP, with JPEG as the fallback if something downstream cannot handle WebP. Both are lossy and both are built for the smooth gradients and noise that photographs are made of.
• Screenshots, logos, diagrams, anything with flat color and hard edges belong in PNG or lossless WebP. Put a screenshot through JPEG and you will see a halo of noise around every letter, because JPEG is designed for exactly the opposite kind of content.
• Anything that needs transparency needs PNG or WebP. JPEG has no alpha channel at all.

The single most common mistake is a PNG of a photograph. PNG will faithfully preserve every last bit of sensor noise in a 12-megapixel photo, at roughly ten times the size of the equivalent WebP. If your image is a photo and the file is a PNG, converting the format is the whole optimization.

WebP is the safe default now. It is supported by every current browser, it is what Lighthouse's "Serve images in modern formats" audit is asking for, and it handles both photographic and flat-color content well - lossy for one, lossless for the other.

What the quality number really means

Quality is not a percentage of anything. It is a knob on the encoder, and the scale is not linear. The interesting range for photographs is roughly 60 to 85.

At quality 90 and above you are spending a lot of bytes for differences you cannot see. Files balloon and almost nothing improves.

At quality 75 to 85 you are in the sweet spot for most photographs. This is where a good encoder gives you a large size reduction with no visible change at normal viewing size. Lighthouse's image audits effectively benchmark against a re-encode at quality 85, so landing near there means the audit stops complaining.

At quality 55 to 70 the file gets meaningfully smaller and fine detail starts to soften. For a hero image or a product shot this is usually too far. For a thumbnail, a background, or an avatar, it is invisible and worth the savings.

Below 50 you will see it: banding in skies, mushy texture, blocky edges around high-contrast details.

The encoder matters too, not just the number. Productivo's image compressor uses MozJPEG for JPEG, libwebp for WebP, and OxiPNG for PNG - the same encoders behind Squoosh, and the ones the Lighthouse image audits are effectively measured against. MozJPEG in particular produces meaningfully smaller files than the default JPEG encoder in most image editors at the same visual quality, because it spends more effort deciding what to discard.

The three presets, and what each one is for

The compressor exposes this as three presets rather than a raw slider, because the format decision and the quality decision are tangled together.

Balanced converts to WebP at quality 80. This is the right answer for almost everything going on a web page. You get the format PageSpeed asks for and a quality level where the result is visually indistinguishable from the original at normal size.

Smallest file converts to WebP and pushes the quality lower, to 55. Fine detail will soften slightly - you can see it if you compare side by side at full size. Use it for images that are never displayed large: thumbnails, list avatars, background textures, email assets where inbox size limits actually bite.

Keep format stays in whatever format you started with, at quality 80. Reach for this when something downstream is picky - an old CMS that only accepts JPEG, a print workflow, a partner's asset spec, a marketplace that rejects WebP uploads. You still get the benefit of a better encoder, just not the benefit of a better format.

For PNG there is no quality setting, because the PNG path is lossless. OxiPNG rewrites the file more efficiently and the pixels come out identical. Savings are more modest - typically 10 to 30 percent - but they are completely free of risk.

How to tell when you have gone too far

Do not judge compression from a thumbnail, and do not judge it from the percentage saved. Judge it the way a visitor will see it.

Open the compressed file at the size it will actually be displayed on your page. If it is a 1200px-wide hero, look at it 1200px wide. Compression artifacts that are glaring at 400 percent zoom are irrelevant if nobody ever sees the image that way.

Then check the places artifacts show up first:

1. Large areas of smooth gradient - skies, studio backdrops, out-of-focus backgrounds. Banding appears here before anywhere else.
2. High-contrast edges - text in the image, product edges against a plain background. Look for a faint halo or ringing.
3. Skin tones and fine texture - fabric, hair, foliage. These go waxy when quality is pushed too low.

If those three look right at display size, you are done. If they do not, step up one preset rather than reaching for quality 95.

Compression will not fix an oversized image

This is the limit worth knowing before you start. Compression changes how efficiently the pixels are stored. It never changes how many pixels there are.

A 4,000px-wide photo compressed to quality 80 is still a 4,000px-wide photo. If it is displayed in an 800px-wide column, you have sent the visitor roughly 25 times more pixel data than their screen can use, and no encoder setting recovers that. The compressor will flag images wider than 2,500px for exactly this reason - wider than most screens ever display - because resizing first will shrink them far more than compression alone ever could.

The compressor deliberately never changes your dimensions. That is a decision, not an oversight: silently resizing someone's images is a good way to ruin a print asset. So if you have oversized originals, resize them first in whatever tool you already use, then compress the result.

Nothing needs to be uploaded

Worth saying plainly, because it changes what you are comfortable running through a tool: the image compressor does all of this in your browser. The encoders are WebAssembly builds that load into a background worker on your machine, and your files never leave your device. There is no upload, no queue, and no copy of your image sitting on a server afterward.

That also means it works on things you would not send to a random website - unreleased product shots, client work under NDA, photos of documents, anything with people in it.

Practically, it means the limits are your machine's rather than a server's: up to 30 images at a time, 50 MB each. Large batches will spin your fan for a few seconds. That is the tradeoff for not uploading anything.

The two-minute workflow

1. Start from originals, not from files you already compressed once.
2. Drop them into the image compressor - up to 30 at a time.
3. Leave it on Balanced unless you have a specific reason not to. Use Keep format if something downstream needs the original format; use Smallest file for thumbnails.
4. Check one representative image at display size, looking at gradients and edges.
5. Download individually, or grab the whole batch as a ZIP.

For a typical page of photographs, that sequence removes somewhere between two-thirds and four-fifths of your image weight, and nobody will be able to tell you did it. Which is the entire point - the best compression is the compression nobody notices.