And what's actually happening inside PNG, JPG, WebP, SVG, BMP, TIFF, HEIC and GIF 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.
DEFLATE alone often isn't enough, so this converter's Compress PNG mode adds an optional lossy step in front of it: reducing the image to a smaller palette of colours (down from up to 16.7 million to as few as a couple dozen, depending on the quality slider), chosen with a k-d tree so the palette fits the image's actual colours well, then mapping every pixel to its nearest palette entry before the usual filtering and DEFLATE pass runs. This is the same idea tools like TinyPNG are built around, and it can shrink a PNG far more than lossless re-encoding alone, at the cost of banding on smooth gradients if pushed too far.
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.
SVG doesn't store pixels, so "compressing" it isn't about discarding visual detail at all — it's about optimizing the underlying XML: shorter path data, merged shapes, stripped editor metadata, plus gzip or Brotli compression at the HTTP layer, which repetitive text markup compresses unusually well with. Converting SVG to PNG trades that resolution independence for a fixed-size pixel grid, so the two formats aren't really compressing along the same axis at all.
Most BMP files are stored pixel-for-pixel with no compression at all, or optionally a simple run-length scheme for images with few colours, which is exactly why they're so large. There's no quality dial to turn: converting a BMP to PNG or JPG is almost always a size win, because it's replacing "no real compression" with an actual codec.
TIFF can be saved compressed, typically with LZW (the same lossless algorithm as GIF) or DEFLATE (the same as PNG), or left completely uncompressed. Either way it's lossless: the choice trades encode/decode speed for file size but never image quality, which is exactly why professional workflows favour it, and exactly why the files are still large enough that publishing on the web usually means converting to JPEG first.
HEIC reuses the HEVC (H.265) video codec's intra-frame tools: variable block sizes up to 64×64 (versus JPEG's fixed 8×8), more precise prediction from neighbouring blocks, and a more efficient entropy coder (CABAC) than JPEG's Huffman coding. The combination is why a HEIC file at visually equivalent quality typically runs 40–50% smaller than the same photo saved as JPEG, at the cost of needing a HEVC-capable decoder to open it.
GIF first reduces every frame to a palette of at most 256 colours, which is where the real size reduction and most of the visible quality loss happens for photographic content, then losslessly compresses the resulting indexed pixels with LZW. That palette step works fine for flat-colour art and screenshots but produces visible banding and dithering on gradients and photos, which is why GIF has been displaced by WebP and video formats for anything beyond short animations.
Try it yourself: the converter's quality slider lets you control this trade-off directly.