JPEG encoders compared: MozJPEG, libjpeg-turbo, Guetzli and jpegli

The JPEG standard specifies how a file is decoded. It leaves considerable freedom in how one is produced: which quantization tables to use, how to round coefficients, how to order the data, whether to search for better choices.

Encoders exploit that freedom differently, and the spread is significant — comfortably more than the difference between quality 80 and quality 82 that people spend far longer worrying about.

Crucially, every one of them emits a standard JPEG. There is no compatibility question: the output opens everywhere, in everything.

A SIMD-accelerated fork of the original libjpeg, and by some distance the most widely deployed JPEG implementation in the world. It is inside browsers, operating systems and most image libraries.

Its priority is speed, and it is extremely fast. Output size is comparable to classic libjpeg — it did not set out to compress harder, only to do the same work faster.

Use it when throughput matters more than the last few per cent, which is most real-time and high-volume work.

Mozilla's fork of libjpeg-turbo, built specifically to produce smaller files at matched visual quality. Its main techniques are trellis quantisation — searching for coefficient values that cost fewer bits without visible cost — and quantization tables tuned against perceptual metrics rather than the 1992 originals. It also defaults to progressive encoding.

The result is typically 5–15% smaller than libjpeg-turbo at equivalent quality, sometimes more. It is slower, but the cost is measured in fractions of a second per image, not minutes.

For build-time optimisation this is usually the right choice: a meaningful saving, a mature codebase, and output that is an entirely ordinary JPEG.

Google's experiment in perceptual encoding, using its Butteraugli metric to search for the smallest file that is still visually indistinguishable from the original.

It produced impressively small files — often 20–30% below libjpeg — and it was extraordinarily slow, frequently taking minutes per image and considerable memory. It also only operates at high quality settings, so it cannot be used for aggressive compression at all.

It has been effectively superseded and is best understood as a research result rather than a tool to deploy.

A more recent encoder from the team behind JPEG XL, which applies techniques learned there to producing ordinary JPEG files. It targets better quality per byte than existing encoders while remaining fast enough for practical use, and it can encode with higher internal precision to reduce banding.

Because its output is a standard JPEG, adopting it carries no compatibility risk — which makes it worth evaluating for anyone running a build-time pipeline. It is newer than the alternatives, so test it against your own content rather than trusting benchmark averages.

These tools encode through your browser's canvas, which uses whatever JPEG encoder the browser ships — usually libjpeg-turbo. That is fast and requires no downloads, and it is not the smallest possible output.

A server running MozJPEG would produce files perhaps 5–15% smaller than what you get here at the same quality. That is a real difference and worth stating plainly.

The trade is that nothing leaves your device. For a photograph headed to a form or a handful of images for a web page, the privacy is worth more than the last tenth. For a production pipeline processing thousands of images, use MozJPEG or jpegli at build time — that is what they are for.