JPEG XL vs PNG for Screenshots: Half the Size, Same Pixels

The short answer

One macOS screenshot, 3056x1982, saved by the system as PNG came to 1,924,519 bytes. Re-encoded to lossless JPEG XL it came to 1,034,300 bytes. That is 890,219 bytes saved, a 46% reduction, for a file that decodes back to the same image.

The catch is not quality, it is compatibility. JXL opens natively on current macOS and in Safari 17 and later, but Chrome and Firefox still keep JPEG XL decoding behind a flag. So the honest recommendation is narrow: JXL is an excellent format for a screenshot you are keeping, and a bad format for one you are about to send.

The test: one screenshot, two formats

The source is an ordinary full-window macOS screenshot of a web page, captured at Retina scale and saved by the system in its default format. The JXL was produced by Mochify's PNG to JXL converter with lossless mode on. Nothing was resized, cropped, or retouched between the two.

Two things in that table deserve more than a row each. The bytes-per-pixel figures explain why the saving happens, and the colour profile row is the one genuine caveat in this whole comparison. Both get their own section below.

Why screenshots compress so well in JXL

PNG compresses in two stages. First it applies one of five per-row filters that predict each pixel from its left and upper neighbours and store the difference. Then it runs the whole filtered stream through DEFLATE, the same general-purpose algorithm as a zip file. That design is from the mid-1990s and it is remarkable how well it has aged, but both halves are limited: the filters only look one row up and one pixel left, and DEFLATE knows nothing about images at all.

JPEG XL's lossless path, called modular mode, replaces both stages with something image-aware. It uses a self-correcting predictor that weighs several different predictions per pixel and learns which is working, it can split the image into regions that get different treatment, and it entropy-codes the residuals with adaptive context modelling rather than a generic dictionary compressor.

Screenshots reward that. A screenshot is full of long exact repeats, hard edges, text rendered with the same antialiasing over and over, and large areas of a single flat colour interrupted by fine detail. PNG's row filters handle the flat areas well and the text poorly. Modular mode handles both, which is where the extra 46% comes from. The bytes-per-pixel numbers say it plainly: 0.318 for PNG against 0.171 for JXL, on identical pixels.

What lossless actually guarantees

We did not take the word "lossless" on trust. Both files were decoded to raw pixels and compared channel by channel, and the comparison is worth reporting carefully, because the first result looks alarming and the explanation is the interesting part.

Compared directly, 12.8% of the colour channel values differed, some by as much as 87 levels out of 255. That is not compression loss. That is the colour profile row in the table above: the PNG is tagged Display P3 and the JXL is tagged sRGB, and converting between two colour spaces changes the numbers stored for a pixel even when the colour it represents stays as close as the smaller space allows. Saturated colours move the most, which is exactly where the large differences landed.

Convert the original to sRGB first, so both files are in the same space, and the comparison changes completely: 99.2% of values are bit-identical, and the maximum difference anywhere in the image is 1 level out of 255. A maximum delta of one is the signature of rounding between two implementations of the same colour conversion, not of a lossy encoder. Lossy compression at any useful quality produces errors many times larger than that, concentrated exactly on the text edges a screenshot is full of.

So the encode is genuinely lossless. The pixels went through unharmed. What changed was the colour space they are described in.

When to use JXL for screenshots (and when not to)

The size argument is settled. The only real question is whether the file will open where it needs to open, and for JPEG XL in 2026 the answer still depends heavily on where that is.

The pattern is consistent: JXL wins wherever you control what opens the file, and loses wherever you do not. That is a compatibility problem rather than a technical one, and it is slowly improving, but it is the state of things today and it is worth planning around rather than hoping past.

How to convert

1. Drop the PNG on the converter.

   Open the PNG to JXL converter and add your screenshots. Up to 3 files a month with no signup and 20MB per file, or 25 a month with a free account.

2. Switch Lossless on.

   This matters. The default PNG to JXL encode is a high-quality lossy pass, because for most PNGs that makes the smallest file and the difference is invisible. For screenshots you want the toggle on, so the result is pixel-exact and still smaller than the PNG.

3. Check the size before you commit.

   Lossless JXL beats PNG on essentially every screenshot we have measured, but a tiny image with very few colours is one case where PNG's palette mode can win. If the output is not smaller, keep the PNG.

4. Keep the PNG if the file is going anywhere public.

   See the support table above. JXL is an excellent archive and Apple-ecosystem format right now, and a poor choice for a file you are about to paste into a bug tracker, a Google Doc, or a web page.

FAQ