How Image Compression Works

Start with the raw arithmetic, because it makes everything after it obvious.

An image is a grid of pixels, each needing three bytes for red, green and blue. So the storage a picture wants before anything clever happens is just width × height × 3:

A 12-megapixel phone photo would be 34 MB with no compression at all, and it arrives as a 3 MB JPEG. That tenfold reduction is not the camera being clever about your particular picture; it is the default behaviour of a format designed in the late 1980s around a specific observation about human eyesight.

Notice too what that table implies about priorities. Halving both dimensions quarters the raw size before any compression is applied. Pixel count is the dominant term, which is why resizing an oversized image saves far more than any quality setting will — a point the sizing guide develops properly.

The conservative approach keeps every pixel exactly and looks for structure to exploit.

Consider a screenshot with a solid grey toolbar. Storing four hundred identical grey pixels individually is wasteful when you could store "this grey, four hundred times". Real lossless image compression is more sophisticated than that — PNG applies a filtering step that stores each pixel as the difference from its neighbours, turning a smooth gradient into a run of small numbers, then compresses the result with DEFLATE — but the principle holds: find repetition, describe it once.

The W3C specification for PNG, now in its third edition, describes the format's purpose as "lossless, portable, well-compressed storage", with filtering and compression that "preserve all information". Decode a PNG and you get back precisely the pixels that went in.

The catch is that this only works when there is redundancy. A screenshot, a logo, a diagram, a chart — large flat areas, hard edges, few distinct colours — compresses beautifully. A photograph of leaves does not: every pixel differs slightly from its neighbours, there is no pattern to exploit, and a lossless encoder ends up storing something close to the full 34 MB. This is the entire reason photographs are not distributed as PNG.

It is also why the quality slider does nothing to a PNG. There is no quality dial on a process that is defined by keeping everything — which is exactly what the compressor tells you when it detects a PNG that will stay a PNG, and why it offers to switch the output to WebP instead.

The aggressive approach accepts that the decoded image will not match the original, and spends its effort on making the difference invisible.

Two facts about human vision make this possible. We are considerably more sensitive to changes in brightness than to changes in colour. And we are poor at noticing fine, high-frequency detail — rapid variation across a few pixels — compared with the broad shapes and edges that carry the meaning of a picture.

JPEG, which MDN describes as "the most widely used lossy compression format for still images", exploits both:

Colour gets less space than brightness. The image is converted from RGB into a brightness channel plus two colour channels, and the colour channels are then stored at reduced resolution — often one colour sample for every four pixels. This is chroma subsampling, and it throws away three quarters of the colour information before compression proper has even started. On a photograph you will not see it. On red text against a blue background, you will.

Detail is sorted by importance and the least important is dropped. The image is divided into small blocks, and each block is transformed with a discrete cosine transform into a set of frequency coefficients — one describing the block's average tone, the rest describing progressively finer variation within it. Those coefficients are then divided by a quantisation table and rounded, which sends many of the high-frequency ones to zero. Zeros compress to almost nothing.

The quality setting is that quantisation table. Turning quality down multiplies the divisors, rounding away more coefficients. It is not a blur and not a resize; it is a decision about how much of the fine detail to keep. Which is why the artifacts have their characteristic look: blocking where the 8×8 grid becomes visible in smooth areas, and ringing around hard edges where the discarded high frequencies were doing the work.

WebP and AVIF apply the same principle with better machinery — MDN describes WebP's lossy mode as "predictive coding based on the VP8 video codec" — and get more compression at the same apparent quality as a result.

Four independent levers, in rough order of how much they typically buy:

1. Fewer pixels. Quadratic, and almost always the biggest win. A 4000-pixel-wide photo shown in an 800-pixel column carries twenty-five times the pixel data it can display.

2. A better format. Free in visual terms, since you are changing the encoder rather than the picture. Google's published figures put WebP at 25–34% smaller than comparable JPEG at equivalent SSIM quality, and 26% smaller than PNG for lossless images. MDN's guide puts AVIF ahead again — a median 50% reduction against JPEG where WebP manages 30% on the same set.

3. Quality setting. Substantial from 100% down to about 80%, then rapidly diminishing while the artifacts grow.

4. Metadata. A camera JPG can carry tens of kilobytes of EXIF, and sometimes an embedded thumbnail and a colour profile. Irrelevant on a 3 MB file; material on a 40 KB icon, and worth removing for privacy reasons regardless.

The practical consequence is an order of operations. Crop to what you are actually showing, resize to the dimensions you will actually display, convert to an efficient format, and only then reach for the quality slider. Most people do it backwards, drag quality to 40%, and get a small ugly file where a resize would have given them a small clean one.

Generation loss is real but often overstated. Re-encoding a lossy file re-quantises it, so damage accumulates: the second save discards detail from an image that has already lost some. In practice one extra round trip at high quality is close to harmless, while repeatedly saving at middling quality visibly degrades a picture. The rule that matters is to keep an original — edit from the source, export once.

Re-compressing an optimised file usually makes it larger. This surprises people. The artifacts introduced by the first compression are themselves high-frequency detail, so the second encoder faithfully spends bytes preserving the first encoder's damage. ToolForge's compressor has a safeguard on by default for this: when the output would be bigger than the input it keeps the original bytes and marks the file "Already optimised" rather than handing you a worse, larger copy.

Lossless-to-lossy is one-way. Converting a JPEG to PNG does not restore anything; you get a lossless copy of a lossy image, typically several times larger with no improvement whatsoever. This is one of the most common wasted operations in image work.

Animated GIFs are a different problem. Canvas-based compression re-encodes a single frame, so an animation comes out as a still — the tool warns about this explicitly rather than silently destroying the animation.

Everything above is background for four practical decisions, each with its own guide:

Just compress this image. The step-by-step version, including which of the presets to use and when target-size mode is the right choice.

Keep it looking good. Where the quality thresholds actually are for photographs, screenshots and graphics, and what "without losing quality" can honestly mean.

Choose a format. JPG, PNG and WebP compared with a decision table, plus where AVIF fits.

It is still too big. The specific reasons — a PNG that stayed a PNG, dimensions rather than quality, an upload limit measured differently than you think.

All of it runs in the compressor on your own machine: files are decoded, re-encoded and measured in the browser, and even the background worker script is served from this site rather than a third-party CDN, so nothing about your photographs reaches a server.