An encoder throws away the detail your eye skips, then packs what survives. The three differ in how hard they push each step.

JPEG (1992) cuts the photo into 8x8 blocks, runs a cosine transform, and rounds off the high-frequency parts. jpegli (Google, 2024) keeps the exact JPEG format but rounds smarter, so it fits roughly 25% more quality into the same bytes as the old mozjpeg encoder. AVIF borrows AV1's video tricks, larger blocks and sharper prediction, so it usually wins on bytes-per-pixel outright.

Right. jpegli stays inside the JPEG bitstream, so a browser from 1995 still decodes it. AVIF needs a modern decoder (Safari 16+, Chrome 85+). That trade, universal but larger against modern but smaller, is why the photo grid ships both and lets the browser pick.

Decode support and encode time. AVIF leans on the AV1 codec, which is slower to encode and only decodes on recent browsers. A tuned JPEG is fast and universal. That is why the site ships a tuned JPEG encoder for the universal fallback and uses AVIF as the primary <picture> source: the browser reaches for AVIF, and anything that cannot decode it falls back to the .jpg. That fallback encoder was jpegli for a long stretch, built from source; since 2026-07 it is zenjpeg, which the grids below measure against it directly.

A color image carries one luma plane (brightness) plus two chroma planes (color). Drop to grayscale and you delete both chroma planes, roughly two-thirds of the color information, so the file falls hard. The garage study has the side-by-side counts.

Right, chroma subsampling. Your eye resolves brightness far better than color, so codecs keep luma at full resolution and shrink the two chroma planes. 4:4:4 keeps everything; 4:2:2 halves chroma horizontally; 4:2:0, the web default, stores one chroma sample per 2x2 block, a quarter of the color resolution. The luma carries the sharpness, so you barely notice.

Exactly, and for photographs it is almost free, because real scenes rarely put fine high-contrast color edges right next to each other. Where it shows is red text on a dark background or saturated line art, which is why screenshots and graphics keep 4:4:4 and 4:2:0 became the default for photos.

It models your eye instead of trusting the fixed 1992 quantization tables. jpegli works in the XYB color space, which spaces colors the way you perceive them, sets the quantization adaptively per block by what you would actually notice, and rounds with adaptive dead-zones. The output is still a standard JPEG that any decoder reads, but more bits land where your eye looks and fewer on detail you would never see. That is the rough 25% it gains over the old mozjpeg encoder.

The site rode jpegli for exactly that reason, then moved to zenjpeg in 2026-07. It reaches the same goal by a different road: hybrid trellis quantization plus a search across 64 candidate progressive scan scripts, which lands a few percent under jpegli at matched quality.

Here is a 96-pixel slice of the car's front wheel, silver spokes over a red caliper, run through every format and blown up so the artifacts show. Start with format against quality.

This one uses a darker crop of the same car, the body edge, because its jpegli cell was encoded once before that encoder left the site's toolchain and cannot be re-cut. Same quality knob, four encoders in the order the site adopted them. The bytes under each tell the story.

A different slice for this one. The body-edge crop is nearly all black and gray, and subsampling only touches color, so all three came out the same. These are bare branches against red glass from a night frame, cut at thumbnail scale and saved as a JPEG at the three chroma samplings. Luma holds; the color is what softens.

Because 4:2:2 describes the camera's frame, and a thumbnail is a much smaller picture. The Fuji frame is 5152 pixels tall; the 600px tile is its centre square shrunk 8.6x, so every tile pixel is an average of an 8.6 by 8.6 patch of the frame. Even at half-width color, that patch holds about four color samples across and nine down.

So at its own size the tile carries full color, measured separately for every pixel. 4:2:0 would average it back down to one color per 2x2 block, throwing away half in each direction.

That's the model, and the garage page measured it. With no compression at all, halving a tile's color and restoring it scores 93.1 to 93.5 on SSIMULACRA2, against 96.3 for the same round trip on a crop at native size. The downscale is what makes subsampling expensive.

Keeping it costs almost nothing, because color in a shrunken photo is smooth and AV1 codes smooth planes cheaply. At the same file size, 4:4:4 scored higher on 18 of 24 photos at the 600px tier; 4:2:0 needs a median 2.2% more bytes to catch up.

Under red light. Red carries only 0.299 of the brightness in the BT.601 matrix these files use, so in a red scene the fine detail lives in the color planes rather than in luma. One night frame of bare branches against red windows, the one the real-photo grid above is cut from, needs 35% more bytes at 4:2:0 to match 4:4:4.

The order the bytes arrive in. Each 8x8 block becomes 64 numbers: one DC coefficient, the block's average, and 63 AC coefficients for finer and finer detail. Quantization rounds them. Everything after that is bookkeeping about how to write them down.

A baseline JPEG writes each block complete, left to right and top to bottom, in one pass called a scan. Half the file gets you the top half of the picture. A progressive JPEG spreads the same numbers across several scans, each covering the whole image. It slices two ways: by frequency (every block's DC first, which is the picture at 1/8 scale, then the coarse AC bands, then the fine ones) and by precision (the high bits of each coefficient first, the low bits in later refinement scans). The decoder adds every scan into one coefficient grid, so when the last scan lands it holds exactly the numbers the baseline file held.

It is, and that is the finding this demo was built to show. zenjpeg searches 64 scan orders for the smallest file, and on this photo the winner sends every bit of brightness first and both color planes last. Chrome waits for every channel to start before it paints anything, so the cutoff lands on the first data byte of the Cr scan, 84.8% of the way through. The order that wins on bytes paints once, at the end, like a slow baseline. Across the library, 156 of 255 color thumbnails wait past their halfway mark.

On a thumbnail that costs almost nothing: the whole file arrives in a round trip or two, and most browsers get the AVIF anyway. It matters on the 20 MB full-size downloads, which the garage study measures: 53 of 256 color originals there hold their color until the last few percent.

It depends on the script, and the three sizes above show it. A progressive AC scan can code a long run of all-zero blocks as one symbol, and each scan can carry Huffman tables fitted to its own statistics, which usually beats one table set for everything. Refinement scans pay some of that back in correction bits. On this photo libjpeg's standard 10-scan script comes out 1.7% larger than baseline, while zenjpeg's searched 7-scan order comes out 0.6% smaller. So a smaller progressive file is a property of a good script, and the search that found this one scored bytes alone.

Each thumbnail is dual-encoded: an AVIF primary at 4:4:4 color and a zenjpeg JPEG fallback inside one <picture>, plus a 400px AVIF tier for phones. The browser loads the smallest format it can decode and never downloads the others.