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, in Safari 17 and later, and since October 2026 in Chrome 155 and Firefox 158 by default; it still does not open in most chat apps, bug trackers, email clients or Windows viewers. So the recommendation is unchanged: JXL is an excellent format for a screenshot you are keeping, and a poor format for one you are about to paste or 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 color profile row is the one genuine caveat in this whole comparison. Both get their own section below.

Why screenshots compress so well in JXL

Because JPEG XL's lossless mode is image-aware and PNG's is not, and on a screenshot that difference is worth roughly 46%. 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 modeling 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 color 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. You can reproduce the pair on your own screenshot with the PNG to JXL converter.

What lossless actually guarantees

Lossless guarantees the pixel values, not the color profile: here every pixel value survived the round trip and only the profile changed, from Display P3 to sRGB. 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 color channel values differed, some by as much as 87 levels out of 255. That is not compression loss. That is the color profile row in the table above: the PNG is tagged Display P3 and the JXL is tagged sRGB, and converting between two color spaces changes the numbers stored for a pixel even when the color it represents stays as close as the smaller space allows. Saturated colors 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 color 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 color 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 late 2026 the answer depends on where that is: browsers, yes, since Chrome 155 and Firefox 158; chat tools, trackers and email, mostly not (current browser support on caniuse.com).

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. If the choice is wider than JXL or PNG, how WebP, AVIF and JPEG XL compare covers the other two.

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. Metadata is stripped on the way through, GPS included, with nothing to set for it on this page; a screenshot rarely carries any, so for this test it made no difference.

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 switch 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 colors 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