JPEG XL vs PNG
Both are lossless, so you get back exactly the same pixels. We checked that on all 20 test images, then measured what it costs. On photos and illustrations JPEG XL wins clearly. On screenshots, a well-optimised PNG beat it unless we let JPEG XL work much harder.
by Robert Castillo · Published
The short answer
For photos and for our illustrations, JPEG XL is clearly smaller. At its default settings it shrank our photos by a third and our illustrations by 41% (43% for the three with real transparency) compared with PNGs already optimised with oxipng's maximum level (-o max, without its slower Zopfli mode), and every pixel came back identical.
For screenshots it is not that simple. At the default effort JPEG XL was bigger than a well-optimised PNG on three of our five screenshots. It only pulled clearly ahead at effort 10, its slowest setting, where in total it cut them by 53% (from 12% to 75% depending on the screenshot). And PNG decodes roughly ten times faster and opens absolutely everywhere, which still makes it the sensible choice for anything you are about to share.
What we tested
Twenty images of four kinds. Eight photos from phones and cameras, all public domain (CC0) from Wikimedia Commons, reduced to 2048 pixels on the long side. Five screenshots of our own website at normal, 2× (laptop) and 3× (phone) pixel density, plus terminal output and a page of code rendered in the browser. Three charts we generated with matplotlib. And four illustrations from Wikimedia Commons, CC0, rendered from SVG; three have a transparent background and soft edges, the fourth, a map, is almost entirely opaque.
Each one was stored as the PNG the program that made it wrote (ImageMagick, Chrome, matplotlib or cairosvg), the "unoptimised" PNG most people actually have; through oxipng 10.2.1 at its default level and at its maximum; and as lossless JPEG XL (cjxl -d 0) at efforts 1, 2, 3, 7 (the default) and 9, plus effort 10 for everything except the photos, where it takes minutes per image.
Results by type of image
The baseline is the best PNG we could make, with oxipng -o max. Totals per group; the percentage is against that baseline.
| Images | Best PNG | JPEG XL default | JPEG XL slowest* |
|---|---|---|---|
| 8 photos | 32.14 MB | 21.55 MB (−33%) | 21.36 MB (−34%) |
| 4 illustrations (3 transparent) | 1.05 MB | 0.62 MB (−41%) | 0.40 MB (−62%) |
| 3 charts | 0.37 MB | 0.27 MB (−26%) | 0.20 MB (−45%) |
| 5 screenshots | 0.74 MB | 0.92 MB (+25%) | 0.34 MB (−53%) |
*Effort 9 for the photos and effort 10 for everything else. JPEG XL at its default effort beat the best PNG on every photo (by 23% to 40%), every chart and every illustration. On screenshots it lost on three of five, by up to 54% on the page of code, which is exactly the kind of image people assume JPEG XL will crush.
Two things soften that. First, most screenshots never go through an optimiser at all: against the PNGs exactly as Chrome saved them, default JPEG XL was 17% smaller in total. Second, effort 10 turns the result around completely: the terminal screenshot shrank to less than half of the best PNG and the page of code to a quarter. The price is time, which is the next table.
What each effort level buys you
Size against the best PNG, and processor time per megapixel on one core. A phone screenshot is typically 2.5 to 4 megapixels; one of our reduced photos is about 3.
| Setting | Photos | Everything else |
|---|---|---|
| oxipng, default level | +0.4% · 1.4 s | +2.9% · 0.7 s |
| oxipng -o max | 0% · 11.6 s | 0% · 9.7 s |
| JPEG XL effort 1 | −13% · 0.07 s | +67% · 0.04 s |
| JPEG XL effort 3 | −29% · 0.38 s | +46% · 0.37 s |
| JPEG XL effort 7 (default) | −33% · 1.8 s | −16% · 0.76 s |
| JPEG XL effort 9 | −34% · 10.9 s | −25% · 3.0 s |
| JPEG XL effort 10 | not run | −56% · 13.9 s |
For photos, effort 1 is the surprise: 13% smaller than the best PNG while using about 160 times less processor time than oxipng -o max. Effort 3 gets most of the way to the default result for a fifth of the time. Above effort 7 there is almost nothing left to gain on photos: effort 9 saved another 0.6% for six times the work, and on one photo we also tried effort 10, which saved 3% more than effort 9 for roughly four times as long again (about two minutes of processor time for 3.1 megapixels).
For screenshots, charts and flat-colour graphics it is the opposite: the low efforts are worse than PNG and the high ones are far better. If you archive screenshots as JPEG XL, use effort 9 or 10 and be patient. Note also that oxipng's default level is almost as good as its maximum, at a tenth of the time.
Is it really lossless? And transparency?
Yes, on everything we tried. We decoded every JPEG XL file (112 of them, across all effort levels) and compared it with the original PNG pixel by pixel, red, green, blue and alpha, with ImageMagick. The number of pixels that differed was zero in every single case. The same check on the oxipng files also gave zero.
That includes the three illustrations with real transparency: the soft, semi-transparent edges round the astronaut, the elephant and the robot came back exactly, and as a group they were where JPEG XL gained most (43% at the default effort). Our three charts carry an alpha channel that is fully opaque, which is what matplotlib writes; both formats kept it without trouble, so you don't need to strip it before converting.
All of this is cjxl on the command line. Our PNG to JPEG XL converter works differently: it is lossy unless you tick “Lossless”, it uses a fast effort setting, and it reads the image through the browser's canvas, which works in 8 bits and can round semi-transparent pixels. For an exact copy of a 16-bit or transparent image, use cjxl -d 0.
Decoding: PNG is about ten times faster
This is the cost nobody puts on the box. On one core, djxl needed 0.33 seconds per megapixel to decode our lossless photos and around 0.19 for the other images. Opening the same pictures as PNG with Pillow, which uses the standard zlib library, took between 0.014 and 0.035 seconds per megapixel.
For a single image on screen that is the difference between a fraction of a second and an instant. For a folder of thousands of files being thumbnailed, or a web page full of large lossless graphics, it is noticeable. Decoders can use several cores, and browsers and viewers do, which narrows the wait, but the work is still about ten times greater.
If your PNG is a photo, ask whether it needs to be lossless
Photos often end up as PNG for no better reason than a screenshot tool or an editor's default. Lossless storage of a photo is expensive in any format: our eight photos took 2.7 MB each on average as lossless JPEG XL.
In our JPEG XL vs JPEG test, the same photos encoded with lossy JPEG XL at visually lossless quality (an SSIMULACRA2 score of 90, where you cannot spot a difference even flicking between the two) came out a median 3.3 times smaller than lossless, and at the still excellent score of 85 about 5.5 times smaller. If the PNG is a master you will edit again, keep it lossless. If it is a photo you just want to keep, lossy JPEG XL at -d 0.5 to -d 1 is the bigger saving by far.
Compatibility in October 2026
PNG's advantage here is total, and it is the one that matters most when a file leaves your hands.
| Where | PNG | JPEG XL |
|---|---|---|
| Chrome, Firefox, Safari | Yes | Yes: Safari 17+, Chrome 155+ and Firefox 158+ |
| Edge | Yes | Not in Edge 155 |
| Windows 11 | Yes | With Microsoft's free JPEG XL Image Extension (24H2 or later) |
| Android | Yes | Not in the official format list |
| Image editors, office apps, email, chat | Everywhere | Patchy: check each one |
PNG is also still moving: its third edition, a W3C Recommendation since 24 June 2025, officially adds HDR colour (through the cICP chunk) and animated PNG. So "PNG can't do HDR" is no longer true on paper, even if support in software is only starting. If you need to know what your own browser does with .jxl, our browser test tells you in a second.
When PNG is still the right choice, and when it isn't
Sharing or uploading → PNG
Every app, editor, chat and web form opens it. That alone settles most cases.
Quick screenshots → PNG
At default settings an optimised PNG beat JPEG XL on 3 of our 5 screenshots, and PNG decodes about ten times faster.
Thousands of files to open → PNG
Lossless JPEG XL decoded about ten times slower in our test. Thumbnails, previews and batch jobs feel it.
Lossless photo archive → JPEG XL
A third smaller than the best PNG at the default setting, with every pixel verified identical.
Illustrations and transparent art → JPEG XL
41% smaller at the default effort, 62% at effort 10, transparency kept exactly by cjxl.
Screenshots you archive → JPEG XL, effort 10
Slow, but in total it cut them by 53% against the best PNG (12% to 75% depending on the screenshot), most on text-heavy ones.
How we measured
Machine and timing: a shared Ubuntu 24.04 server with 6 virtual AMD EPYC cores. Every command ran on one thread (cjxl --num_threads=0, oxipng -t 1), one after another, capped at 2.5 GB of memory and at the lowest priority, so the server's websites came first. Times are processor time (user plus system), which other load on the machine barely affects; read them as ratios rather than as what your own computer will do.
Tools: libjxl 0.12.0 (cjxl, djxl), oxipng 10.2.1, ImageMagick 6.9.12 for resizing and for the pixel comparison (compare -metric AE on all four channels), Pillow 12.3 for PNG decoding times, Chrome 146 for the screenshots, matplotlib 3.10.8 for the charts and cairosvg 2.9.0 for the illustrations.
Commands: oxipng -t 1 -o 2 and oxipng -t 1 -o max; cjxl in.png out.jxl -d 0 -e E --num_threads=0 with E = 1, 2, 3, 7, 9 and 10; djxl out.jxl check.png for the pixel check and djxl out.jxl out.pam --num_threads=0 for decoding time.
Limits: this is a small sample, not a study. We planned 16 photos and ran 8 (four from phones, four from cameras) because the test had to be slowed down and run one command at a time on a server that also hosts websites; effort 10 was not run on photos. We did not test tiny images such as icons, where file overhead matters more, nor PNG's slowest optimiser, zopfli. The photos come from JPEGs and were reduced, so they are cleaner than a raw development; real lossless photo files may compress differently. Scripts, results per image as CSV, and the source and licence of every image are kept with the measurements.