How to Compress Images for the Web Without Wrecking the Quality

Why re-saving a JPEG degrades it, what the quality slider actually controls, and why resizing matters more than any compression setting.

Almost every "compress your images" guide stops at the point where it should start. Upload a file, move a slider, download something smaller. That works until the day it doesn't — the logo develops a grey halo, the product photo goes blotchy in the shadows, or the file you compressed twice looks visibly worse than the one you left alone. Understanding why those things happen takes about ten minutes and saves a lot of re-exporting.

Lossy and lossless are not quality settings

The first distinction is the one that explains most surprises. Lossless compression stores the same pixels in fewer bytes — unpack it and you get back exactly what you put in. PNG works this way. Lossy compression throws information away permanently and stores an approximation. JPEG works this way, and so do WebP and AVIF in their default modes.

That difference has a consequence people run into constantly: lossy compression is not repeatable without cost. Every time you save a JPEG, it is re-analysed and re-approximated from whatever the previous save left behind. Do it five times and you are approximating an approximation of an approximation. This is why an image that has been through a few rounds of upload, download and re-save looks soft and blocky even though nobody ever chose a low quality setting. If you are going to compress, compress once, from the best original you have.

The quality slider is not a percentage of anything

A JPEG quality setting of 80 does not mean "80% of the original quality". It is an index into a table of quantisation values that control how aggressively fine detail gets discarded. The relationship between that number and both file size and visible quality is steeply non-linear, and that is what makes it useful.

Going from quality 100 to quality 90 typically removes a very large share of the file size while producing a difference almost nobody can see on a screen. Going from 90 to 80 usually removes a lot more size for a difference that is still hard to spot on photographic content. Going from 80 to 70 starts to show, and below about 60 the artefacts become obvious — blocky 8x8 squares in flat areas, and coloured fringing around hard edges.

This is why the 80 to 85 range is the standard recommendation for photographs on the web. It is not a magic number, it is the region where the curve has already given you most of the savings and has not yet started charging you in visible damage. If you only remember one thing, remember that quality 100 is almost always a waste: it can easily double the file size versus quality 90 for no perceptible gain.

Match the format to the content, not to habit

Format choice usually matters more than the quality slider, and the right answer depends on what is actually in the image.

Photographs — continuous tone, lots of gradual colour variation, no hard edges — are what JPEG was designed for and what it still handles efficiently. WebP does the same job at roughly 25 to 35 percent smaller for equivalent perceived quality. AVIF does better again, often around half the size of a comparable JPEG, and handles dark gradients noticeably better, which matters for night photography and moody product shots where JPEG tends to band.

Screenshots, diagrams, logos and anything with text or flat colour are the opposite case. These have hard edges and large uniform areas, which is exactly what lossy compression handles worst — you get ringing artefacts around every letter. PNG is lossless and compresses flat colour extremely well, so a screenshot saved as PNG is frequently both smaller and dramatically sharper than the same screenshot saved as JPEG. Saving a screenshot as JPEG is one of the most common and most visible compression mistakes.

Anything needing transparency rules out JPEG entirely, since it has no alpha channel. Save a transparent PNG as JPEG and the transparency is flattened onto a solid background — usually black or white — which is generally discovered after the original has been overwritten.

Dimensions do more than compression ever will

Here is the thing that dwarfs every other consideration, and the one most sites get wrong: the fastest way to shrink an image is to stop serving one that is far larger than it is displayed.

A 4000 pixel wide photograph displayed in a 600 pixel wide column is carrying nearly 45 times more pixel data than the screen can use. No quality setting rescues that. Resizing to roughly twice the displayed width — enough to stay sharp on high-density screens — and then compressing typically produces a file a fraction of the size of the original at any quality setting, with no visible difference at all.

The practical order of operations is therefore: resize first, then choose the format, then set the quality. Doing it in the other order means you are carefully optimising a file that should not have been that size in the first place.

What actually changes your page speed

Images are usually the largest thing a page downloads, which makes them the usual culprit behind a poor Largest Contentful Paint score. But the relationship is not simply "smaller files are faster".

What matters most is the one image the visitor sees first — typically the hero. Getting that image small and getting it to start downloading early affects the measured experience far more than shaving kilobytes off images further down the page, which a visitor may never scroll to. Images below the fold should be lazy-loaded so they do not compete for bandwidth with the content that is actually on screen.

The other half is layout stability. An image without width and height attributes has no reserved space, so the page reflows when it arrives and everything below it jumps. That shows up as Cumulative Layout Shift, and it is one of the more irritating things a page can do to someone who has already started reading. Setting explicit dimensions costs nothing and fixes it completely.

A workflow that holds up

Start from the largest original you have, not a copy that has already been through a messaging app. Resize to about twice the display width. Pick the format by content type — WebP or AVIF for photographs, PNG for anything with text or transparency. Compress once at quality 80 to 85 and compare against the original at full size before accepting it. Set width and height in your markup. Lazy-load everything below the fold.

Do that and the typical result is a page whose images are a small fraction of their original weight with no quality complaint from anyone — which is the entire point of the exercise.