How Image Compression Works: JPEG vs WebP Quality Explained

Every image compressor, including ours, offers a quality slider. It looks like a simple dial between “small” and “sharp”, but what it actually controls is how much visual information the encoder is allowed to throw away. Knowing what gets discarded, and how JPEG and WebP differ in the way they do it, makes it much easier to choose settings that keep pictures looking good while cutting their size dramatically.

Lossless and lossy: two different promises

A lossless format such as PNG stores every pixel exactly. Decompress it and you get back the identical image, bit for bit. That is ideal for screenshots, diagrams, logos and anything with sharp text, but photographs compress poorly this way because natural scenes are full of fine, random variation that cannot be described compactly without losing something.

A lossy format such as JPEG, or WebP in its lossy mode, makes a different promise: the decoded image will look nearly the same to a human, not be the same. It exploits the fact that our eyes are much better at noticing changes in brightness than in colour, and much better at seeing broad shapes than tiny, high-frequency texture. Detail that you would not notice is simply not stored.

What JPEG does to a photo

JPEG, standardised in 1992, still works in a few clear steps:

1. Colour conversion. Red, green and blue values are converted into one brightness channel (luma) and two colour channels (chroma).
2. Chroma subsampling. The colour channels are usually stored at half the width and half the height of the brightness channel, a scheme called 4:2:0. That alone discards half of the raw data, and most people never notice.
3. Splitting into 8 × 8 blocks and applying a discrete cosine transform (DCT) to each one. The DCT re-describes a block as a mix of smooth gradients and progressively finer patterns.
4. Quantisation. Each of those pattern strengths is divided by a number from a quantisation table and rounded. Fine patterns get divided by larger numbers, so many of them round to zero. This is the step the quality slider controls: lower quality means larger divisors and more zeros.
5. Entropy coding. The remaining numbers, now full of zeros, are packed efficiently with Huffman coding.

Because the blocks are processed independently, heavy compression shows up as blocking (a visible 8-pixel grid in smooth areas like skies) and ringing (faint halos next to sharp edges and text).

How WebP differs

Lossy WebP, released by Google in 2010, borrows its core from the VP8 video codec. Instead of coding each block from scratch, it first predicts a block from the pixels already decoded above and to the left of it, then encodes only the difference between the prediction and reality. Smooth areas are predicted well, so there is very little left to store. The residual is transformed in small 4 × 4 blocks, quantised, and compressed with an arithmetic coder, which squeezes data more tightly than JPEG's Huffman coding.

WebP also applies an in-loop deblocking filter that smooths block boundaries. As a result, a WebP pushed too far tends to look soft or smeared rather than blocky. Google's own comparative study reported lossy WebP files around 25–34% smaller than JPEG at equivalent measured quality; in day-to-day use, savings of 20–30% at similar visual quality are a reasonable expectation, with large variation from image to image.

Two more practical differences: WebP supports an alpha channel in lossy mode, so a photo cut-out can be both small and transparent, which JPEG cannot do at all. On the other hand, lossy WebP always uses 4:2:0 colour subsampling, so thin saturated details, such as red text on a blue background, can blur more than in a carefully tuned JPEG.

What the quality number really means

A quality of 80 is not “80% of the original”. It is an input to a particular encoder's internal formula, and different encoders map it differently. JPEG at 80 from one program is not identical to JPEG at 80 from another, and WebP at 80 is certainly not equivalent to JPEG at 80. Treat the number as a relative dial for one tool, not a universal measurement.

What does hold across encoders is the shape of the trade-off. Dropping from 100 to around 90 removes a surprising amount of data for almost no visible change. From 90 down to roughly 75, files keep shrinking quickly while differences remain hard to spot at normal viewing size. Below about 60, savings slow down and artefacts start to show, first in smooth gradients and around text.

A practical recipe

1. Resize first. Pixel count dominates file size. A 12-megapixel phone photo displayed 1200 pixels wide is carrying many times more pixels than anyone will see. Use the Image Resizer before compressing.
2. Pick the format by content. Photos: WebP, or JPEG where compatibility matters. Screenshots, charts, logos and text: PNG, or lossless WebP.
3. Start at 80 and compare. In the Image Compressor, look at the output at 100% zoom in the areas most likely to suffer: skies, skin, and edges against plain backgrounds. Lower the quality until you can see a difference, then step back up a little.
4. Compress once, from the original. Each lossy save discards a little more information. Re-compressing an already-compressed JPEG compounds the damage, a problem known as generation loss. Keep your originals and always export from them.
5. Mind the metadata. Photos straight from a phone may include the GPS location where they were taken. Re-encoding through a browser canvas does not copy EXIF data, which both saves space and removes that information.

When compression does not help

Sometimes the output is larger than the input. That usually means the original was already compressed hard, or it was a PNG with a small number of flat colours, which PNG stores very efficiently and a photo codec does not. In those cases, keep the original. A good compressor should tell you this honestly instead of handing you a bigger file, which is exactly what ours does.

Finally, compatibility. Every current version of Chrome, Edge, Firefox and Safari displays WebP, and most content management systems accept it. Some older desktop software, email clients and upload forms still expect JPEG. If you are not sure where an image will end up, JPEG at a quality of 80–85 remains the safe, universally readable choice — and you can always produce a WebP copy for the web with the Image Converter.