The Complete Guide to Image Compression

Every image file trades two things against each other: file size and information. Compression is the general term for algorithms that shrink that file size, and it splits into two families. Lossless compression (PNG, GIF, and the lossless mode in WebP/AVIF) rearranges and re-encodes pixel data so it can be perfectly reconstructed — nothing is discarded, so the file only gets smaller by removing genuine redundancy, like repeated runs of the same color. Lossy compression (JPEG, and the lossy modes of WebP/AVIF/HEIC) goes further: it discards information a viewer is statistically unlikely to notice — subtle color gradients, fine texture, frequencies the eye is less sensitive to — and doesn't try to reconstruct it exactly. That's why a lossy JPEG at 80% quality can be a fraction the size of the same photo saved as lossless PNG: it isn't compressing harder, it's throwing more away. Which family to reach for depends entirely on the image and what happens to it afterward.

JPEG is lossy and built for photographs. It converts an image from RGB into a luminance/chrominance color space, then typically halves the resolution of the two color channels while keeping brightness at full resolution — a step called chroma subsampling, which works because human eyes are far more sensitive to brightness detail than to color detail. Each 8x8 pixel block then goes through a discrete cosine transform (DCT), which separates it into frequency components, and a quantization table discards the frequencies contributing least to how the block looks — the exact step a JPEG quality number controls. Higher quality keeps more frequencies; lower quality rounds more of them to zero, which is what eventually produces the blocky, smudged artifacts visible around edges and text at low settings. JPEG has no alpha channel, so it can't represent transparency, and because it's lossy, re-saving the same JPEG repeatedly compounds generation loss. It remains the safest default for photographic content without transparency.

PNG is lossless by design — built for screenshots, logos, line art, and anything with flat color or text where a single wrong pixel is obvious. It applies a predictive filter to each scanline (guessing each pixel's value from its neighbors and storing only the difference), then runs the result through DEFLATE, the same general-purpose compression used in ZIP files. Because none of that touches actual pixel values, PNG output is always full fidelity, and this shows up directly in how compression tools behave: pixeltools' own compressor calls the browser's canvas.toBlob() API with a quality argument, but browsers — Chrome, Firefox, and Safari alike — silently ignore that argument for PNG, since PNG is defined as lossless and there's no quality axis to turn down. That's why dragging a quality slider to 50% on a PNG produces a file identical in size to 100%: the knob has nothing to act on. Actually shrinking a PNG means changing the pixels — reducing the color palette, resizing the image, or switching to a format with a real lossy mode.

WebP and AVIF are newer formats that support lossy and lossless modes plus a real alpha channel, so a single format can replace both JPEG and PNG for most use cases. WebP uses a lossy scheme derived from Google's VP8 video codec and typically produces files in the range of 25-35% smaller than JPEG at visually equivalent quality — a commonly cited figure, though the exact gap depends heavily on the image. AVIF, based on the AV1 video codec, generally pushes further still, especially at aggressive compression levels, because AV1's newer prediction and transform tools tend to handle gradients and fine detail more efficiently than JPEG's or WebP's older techniques. The tradeoff is encode time — AVIF encoding is noticeably slower — and, historically, tooling support. Both are now supported by every major browser, but some older software, email clients, and CMS plugins still choke on them, so keeping a JPEG or PNG fallback is worth it for anything distributed outside a browser you control.

GIF predates JPEG and works on a completely different principle: instead of a quality curve, every GIF is limited to a palette of at most 256 colors, indexed and then losslessly compressed with LZW. That palette ceiling is why GIF is a poor choice for photographs — smooth gradients and skin tones band visibly once squeezed into 256 colors — but a fine one for simple animations, screen captures, and graphics with large flat areas. Re-compressing a GIF doesn't involve a JPEG-style quality knob at all: pixeltools' own GIF recompression reduces the palette size itself, computing the target color count as 2 raised to (quality times 8, rounded), capped between 2 and 256 colors, then re-quantizing every frame to that smaller palette. A quality of 50% on a GIF, in other words, means keep roughly 16 colors instead of 256 — not keep 50% of the original detail the way it would for a JPEG.

For JPEG and WebP, quality settings in the 75-85 range are the sweet spot for most photographic web images — high enough that artifacts aren't visible at normal viewing sizes, low enough to cut file size substantially versus 100%. Below roughly 60, blocking and banding start becoming visible on close inspection; above 90, file size climbs fast for almost no visible gain. The best way to pick a number is to compare the compressed output against the original at full zoom, not to trust the percentage alone — the same numeric setting looks different on different images. One gotcha catches people constantly: converting a transparent PNG or WebP to JPEG doesn't produce a transparent JPEG — it can't, since JPEG has no alpha channel — so a compressor has to decide what replaces the transparent area. pixeltools' compressor fills it with solid white before drawing the image, standard behavior that matches most tools, but it means a logo with a transparent background comes out with a hard white background after JPEG conversion. If transparency needs to survive, stay in PNG, WebP, or AVIF.

With the mechanics out of the way, format choice comes down to a few quick questions. Does the image need transparency? If yes, rule out JPEG entirely — use PNG for flat graphics and screenshots, or WebP/AVIF for anything where lossy compression with alpha still beats lossless PNG on size. Is it a photograph with no transparency? JPEG remains a safe universal default; WebP is worth using instead wherever the destination supports it, since it usually beats JPEG at equivalent visual quality. Is it a simple animation? GIF still works, but an animated WebP or AVIF is usually smaller for the same result where the platform supports it. Is it line art, a logo, or text-heavy graphic? PNG — or SVG, if it's genuinely vector — beats every photographic format. Once the format is right, run the image through an actual compressor rather than assuming format alone solved it; comparing output size and quality before downloading removes the guesswork from that last step.