JPEG quality versus file size: the curve, explained without the maths

A JPEG encoder splits the image into blocks, converts each block into a frequency description, and then divides the high-frequency detail by a table of numbers derived from your quality setting. A high quality setting divides by small numbers, so detail survives. A low one divides by large numbers, so fine detail is rounded away — that is where the visible mush in the corners of an over-compressed photo comes from.

Quality also influences two other decisions. Chroma subsampling describes how much colour resolution is thrown away relative to brightness: at high quality, encoders keep full colour detail (often written 4:4:4); at moderate quality they halve it (4:2:2) or quarter it (4:2:0). The eye is far less sensitive to colour detail than to brightness, which is why 4:2:0 is nearly invisible on photographs and disastrous on red text on a white background. Progressive encoding is the other: it stores the image in several passes so a viewer can show a blurry version quickly, at a small size cost and a large perceived-speed benefit.

Our compressor uses MozJPEG with progressive encoding and optimised Huffman coding, and runs a search over integer quality values from 4 to 98 to find the highest quality that still lands inside your size target.

The relationship between quality and file size is not straight. Going from 100 to 95 can halve the file for a difference nobody can see at normal viewing distance. Going from 50 to 40 might save 15% and make the image look obviously worse. Between roughly 75 and 90 there is a plateau where a few quality points cost very little and protect the image from visible damage.

That asymmetry has a practical consequence: when you are trying to reach a small target, the productive move is usually not quality at all. Reducing the pixel dimensions cuts size in proportion to area — halving the width and height quarters the data — whereas squeezing the last 10 KB out of the quality slider costs real visual quality.

Quality 80 applied to a portrait against a wall might give a 60 KB file. Quality 80 applied to a photograph of a crowded street might give 900 KB. The setting is the same; the content is not.

JPEG stores the difference information between blocks. A smooth wall produces almost no high-frequency detail, so there is nothing to store and the encoder skips it efficiently. A street scene with leaves, gravel, clothing patterns and text on signage is packed with exactly the detail JPEG spends its bytes on. This is also why a photograph of a printed document compresses far better than a photograph of a bookshelf, and why "make it under 50 KB" has an honest answer that depends on the picture.

If you are chasing a hard cap and the content is uncooperative, resolution is the lever that always works. Cropping empty background is the other: a photo where the subject occupies a third of the frame wastes two thirds of the file on things nobody needs.

Decoding a JPEG produces an approximation of the original image. Encoding that approximation produces a second approximation, and the errors from the first pass get processed as if they were real detail. Do it ten times and the image is visibly degraded, with a halo of artefacts around every edge — the classic generation loss.

The fix is procedural rather than technical: edit from the original, keep one master file, and save derivatives only when you are done. If you must re-save a compressed file, set the quality higher than the file’s apparent quality, so the encoder spends its budget preserving what is there rather than thinning it further.

For the same visual quality, WebP generally produces a file 25 to 35% smaller than JPEG, and AVIF manages 40 to 50% smaller — partly by using better entropy coding, partly by modelling the image in larger blocks and adapting to its content.

Two reasons JPEG still wins in practice. First, acceptance: passport portals, exam applications and older corporate systems list "JPEG" as a requirement, and an unaccepted WebP is worth nothing however efficient it is. Second, speed: AVIF encoding is computationally heavy — several seconds for one large photograph, compared with milliseconds for JPEG. Our compressor defaults to JPEG for exam and portal targets for exactly this reason, and offers WebP and AVIF where the destination is a website you control.

Set the target first, then let the search find the quality. That is what the tool does: you enter 50 KB, it encodes, measures, and narrows the quality range until the file is within a kilobyte of the target without going under it more than necessary — a ±1 KB band under 100 KB, and 2% above that.

A sensible manual order, if you prefer to do it yourself: crop to what matters, set the resolution to the smallest that stays legible (for photographs of documents, 150 DPI at the final page size is usually enough), grayscale if colour carries no meaning, and only then lower quality until the size lands.