And what's actually happening inside PNG, JPG and WebP when they shrink a file.
Images are usually the single largest contributor to a web page's total weight, and page weight translates directly into load time. Every extra kilobyte costs real time on a mobile connection, and load time is a measurable factor in bounce rate, conversion rate, and Google's Core Web Vitals, which feed directly into search ranking.
Beyond speed, smaller files mean lower bandwidth and storage costs for whoever is hosting or serving the images, and a better experience for users on slower networks or capped data plans. Many everyday contexts also impose hard limits — email attachment caps, web form upload limits, CMS media constraints — where a file simply has to be made smaller to be usable at all.
The goal isn't just "smaller" — it's smaller without the loss being visible. That's the balance a compression quality setting is designed to control.
Before compressing, PNG runs each row of pixels through a filter that predicts a pixel's value from its neighbours (options include Sub, Up, Average, and Paeth) and stores only the difference from that prediction. Flat colour and repeating patterns produce long runs of near-identical residuals, which the DEFLATE algorithm (LZ77 pattern-matching plus Huffman entropy coding) then compresses efficiently. Because nothing is discarded, PNG's compression ratio is bounded by how much genuine repetition and predictability exists in the image — it's excellent for flat-colour graphics and text, but photographic noise and gradients compress poorly, which is why PNG photos are large.
JPEG first exploits the fact that human vision is far more sensitive to brightness than to colour, so it downsamples the colour channels (chroma subsampling, typically 4:2:0) with almost no perceptible effect. It then splits the image into 8×8 blocks and applies a Discrete Cosine Transform to convert each block into frequency components. The quality slider controls a quantization step that divides those frequency components by a scaling table and rounds the result — this is where detail actually gets discarded, concentrated in the high-frequency information the eye notices least. What remains is compacted further with run-length and Huffman coding. Quality 100 is close to lossless-sized; 75–85 is the usual sweet spot; below ~50 the discarded blocks become visible as blockiness.
Lossy WebP inherits VP8's intra-frame prediction: each block is predicted from already-decoded neighbouring blocks, so only the (usually small) residual difference needs to be transformed, quantized, and encoded — a more efficient starting point than JPEG's independent blocks. Entropy coding uses an arithmetic coder rather than Huffman, which packs bits more tightly. Lossless WebP takes a different route: it applies a predictor transform (similar to PNG's filtering, but with 14 directional predictors instead of 4), a colour transform that decorrelates the RGB channels, and a colour-indexing transform for images with few distinct colours, then compresses the result with its own backward-reference and entropy coding scheme tuned specifically for images rather than generic data. That image-specific tuning is why lossless WebP consistently beats PNG's generic DEFLATE at the same quality.
Try it yourself: the converter's quality slider lets you control this trade-off directly.