How image compression actually works, and where quality really goes

A quality slider is not a dial for "how good the picture looks". In a JPEG encoder it scales a table of divisors that decide how coarsely each kind of visual detail is rounded off. That is the whole trick, and once you can see it, most advice about compression either makes sense or falls apart.

Lossless compression (PNG, ZIP, lossless WEBP) writes the same pixels in fewer bytes by finding structure, and decodes back to the original exactly. Lossy compression (JPEG, lossy WEBP, AVIF) replaces the pixels with cheaper ones you are unlikely to notice. The useful question is what each codec chooses to sacrifice.

JPEG: built around the shape of human vision

A JPEG encoder does four things to your photo.

First, it converts RGB into YCbCr: one brightness channel (Y) and two colour channels (Cb, Cr). That matters because your eye resolves fine brightness detail far better than fine colour detail.

Second, it cuts the image into 8x8 pixel blocks and runs a discrete cosine transform on each. The block's 64 pixel values become 64 coefficients describing it as a sum of patterns, from flat, through gentle gradients, up to fine checkerboards. Nothing is lost yet; this step is reversible.

Third, and this is where quality goes, each coefficient is divided by a number from a quantisation table and rounded to an integer. The table has small divisors for coarse patterns and large ones for fine patterns, so dividing a high-frequency coefficient by 80 and rounding turns small amounts of fine detail into zero, permanently.

Fourth, the mostly-zero coefficients are read in zig-zag order, run-length coded and Huffman coded. That step is lossless, and it is where the file actually gets small, because long runs of zeros cost almost nothing.

So JPEG does not blur your photo. It discards specific frequencies inside specific blocks, which is why its failures look the way they do: ringing around black text, blockiness in smooth sky, mosquito noise along high-contrast edges.

What the quality slider actually changes

In libjpeg, the library behind most encoders including the one in your browser, quality is a single multiplier applied to the standard quantisation table. Quality 50 uses the table as published. Above 50 the divisors shrink, so less is rounded away; below 50 they grow, and detail disappears fast. Because it is one multiplier over a fixed table, the mapping is far from linear:

• 95 and above: divisors near 1, files large, differences invisible. Worth it only for a master copy or before printing.
• 80 to 92: the working range. For most photographs, 85 is indistinguishable from the original at 100 percent zoom, at about a quarter of the bytes of 95.
• 60 to 80: where web images live, visible only if you know where to look.
• 40 to 60: blocking becomes findable, text edges fringe. Below 40, damage is obvious on anything with edges or gradients.

The quality number is not portable between encoders. JPEG quality 80 from one library and 80 from another can differ in size by 20 percent, because their base tables differ. Comparing quality numbers across tools tells you nothing; comparing the resulting KB tells you everything.

Chroma subsampling, in plain words

Because your eye is weaker at colour detail than brightness detail, JPEG encoders normally store the two colour channels at half resolution in each direction. Every 2x2 group of pixels keeps its four brightness values and shares one pair of colour values. That is 4:2:0 subsampling, and it removes three quarters of the colour information before quantisation has started.

On a photograph of a person or a street you will not see it. You will see it on saturated red or magenta text against a dark background, where letters gain a blurry coloured halo because their edges live mostly in the colour channels; on thin coloured lines such as a chart gridline; and on hard colour boundaries in flat graphics.

That is the real reason a screenshot of coloured text looks bad as JPEG at any quality: the damage is from subsampling, not from the quality setting. 4:4:4 keeps colour at full resolution for 15 to 25 percent more bytes. Lossy WEBP always uses 4:2:0 with no option, so it inherits the same weakness.

PNG: lossless, and huge for photos

PNG does two passes. First a per-row filter predicts each byte from its left neighbour, the row above, the average of both, or the Paeth predictor, and stores only the difference; on a smooth gradient those differences are tiny and repetitive. Then the filtered data goes through DEFLATE, the LZ77-plus-Huffman algorithm from ZIP.

It is exactly reversible. Save a PNG a thousand times and the pixels never change, which is why PNG is the right format for a master file you keep editing, and the wrong format for a photograph. Camera noise makes neighbouring pixels unpredictable, so filters find no pattern and DEFLATE has nothing to work with. A 12 megapixel photo as PNG runs to 10 to 20 MB, fifteen times the JPEG at quality 80, with no visible advantage. Where PNG wins is flat colour and hard edges: logos, icons, diagrams, interface screenshots.

WEBP: both modes, one extension

Lossy WEBP borrows from the VP8 video codec. Before transforming a block it predicts it from already-decoded neighbours, then encodes only the prediction error. That is why it beats JPEG: a smooth region costs almost nothing once the predictor has guessed it. Google's own comparison puts lossy WEBP 25 to 34 percent smaller than JPEG at matched quality.

Lossless WEBP is a different algorithm again, with spatial predictors, a colour transform and a cache of recent colours; Google measured it about 26 percent smaller than PNG. Both modes support a full alpha channel, which JPEG cannot do at all.

The catch: many browser-based encoders, including the one behind the tools here, only write lossy WEBP. For a flat-colour logo, keep quality at 90 or above so edges stay clean.

Why re-saving a JPEG degrades it, and when it does not

Generation loss is real, but the mechanism is more specific than the warning suggests. Decode a JPEG and immediately re-encode it at the same quality with the same encoder and no editing, and the coefficients are already multiples of that quantisation table, so most survive rounding unchanged. Loss after the first generation is small.

Damage compounds when something breaks that alignment:

• A crop that is not a multiple of 8 pixels shifts the block grid, so every block is re-analysed and re-quantised from scratch.
• Resizing resamples pixels, creating new frequency content that the next quantisation attacks.
• A different quality setting, especially a higher one, recovers nothing and adds a second rounding.
• Rotating by anything other than 90 or 180 degrees, and any brightness or contrast edit, moves every coefficient.

Keep one lossless master, the camera file or a JPG to PNG copy, edit from that, and export a fresh JPEG each time. Do not use last week's JPEG as this week's source.

Same photo, five encodings

One 4000x3000 outdoor photograph with foliage and sky, through a browser encoder. An example, not a specification: a studio shot on a plain background compresses two to three times better, a noisy indoor photo worse.

The interesting row is quality 85. Going from 95 to 85 removed more than half the file and nothing you can see; going from 85 to 40 removed another 80 percent and wrecked the picture.

Test it on your own photo

Numbers from an article are worth less than numbers from your own image. Ten minutes with the Image Compressor settles it:

1. Run the same photo four times, at quality 90, 75, 60 and 40, with the quality in each file name.
2. Open all four plus the original in separate tabs at 100 percent zoom, not fit-to-window, which hides everything.
3. Check four places: a smooth sky or wall gradient, hair or foliage against a bright background, any small text, and any saturated red area.
4. Flip between tabs at the same zoom and scroll position. A difference you cannot see when flipping does not exist for your viewers either.
5. Note the KB on each result card and pick the lowest quality where flipping shows you nothing.

For a photograph that is usually 70 to 85. For a screenshot with text it will be above 90, which is your signal to use PNG or WEBP instead. If the tool reports a file as already optimal, re-encoding would have made it bigger and it kept your original.

Two limits. Lossy compression is not reversible, so keep the original before batching anything. And if you are compressing to satisfy a fixed KB cap on a form, the quality slider is the wrong tool: Reduce Image Size in KB searches for the quality that fits your number.

Frequently asked questions

Can I compress an image without losing any quality at all? Only with a lossless format or a lossless optimiser. Converting a photo to PNG loses nothing but usually makes it larger. Genuine lossless JPEG optimisation, which rewrites the Huffman tables without touching coefficients, saves about 5 to 20 percent. Anything promising 80 percent off with no loss is lossy compression under another name.

Does compressing an image reduce its pixel dimensions? No. A quality slider changes only how the same grid of pixels is encoded. Reducing dimensions is a separate operation, and doing both is the fastest route to a small file, which is why the compressor has an optional max width.

Why did my PNG get bigger after compression? PNG has no lossy mode, so the encoder can only pack the same pixels differently, and a file that was already well packed comes out slightly larger. Choose JPG or WEBP output for photographs.

Is WEBP always the right choice now? For anything you serve on a website, close to it. For a file someone will download, email, print or upload to a government portal, JPEG is still the safe answer, so JPG to WEBP is a decision about your pages, not theirs.