JPEG XL file format

"download up-to-date versions of the cjxl.exe encoder (Binaries "
This is version 0.7

I found information from one of the fathers of the format:
Jon Sneyers @jonsneyers
Jpg => cjxl -q 80 preserves metadata fine, but djxl wrote it to jpg incorrectly (will be fixed soon)
See also:
I decided to convince myself of the correctness of the Metadata behaviour in the jxl file
To do this, I downloaded the file Loch Faskally, autumn colours
and I converted it first into: Convert to JPEG XL (JXL) Online | Compress Images | MConverter
result - all data stored
So to make sure, I converted this file in my computer and the result is identical. The EXIF metadata after conversion to jxl is preserved as long as the image file has it.

9.5 Exif box

The type of this box shall be given by the 4 bytes 0x45 0x78 0x69 0x66 (“Exif” in ASCII).

6 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC FDIS 18181-2:2021(E)
Figure 6 shows the contents of an Exif box, excluding the box header.
Figure 6 — Content of an Exif box
[6] [7]

The Exif payload is as described in JEITA CP-3451E or CP-3461B . The tiff header offset denotes, as

specified in JEITA CP-3451B, the number of bytes, counting from the first byte of Exif_payload to the

first byte of the TIFF header of the Exif metadata. The value is zero if the payload starts immediately

with the TIFF header.

NOTE 1 The content of this box is exactly ExifDataBlock as defined in ISO/IEC 23008-12:2017, A.2.

For any Exif fields that have equivalents within the codestream, a decoder shall consider the codestream

to take precedence. Encoders are encouraged to ensure the Exif and codestream fields are identical.

NOTE 2 Examples of such fields include orientation and pixe……

The official gitlab source repo lists changes and most releases there get a changelog of some sort.

On one or more of the people involved are quite involved and active on the forum.

I try not to download binaries from unknown sources. Version 0.7 is not yet released on github or gitlab.

Yes, I was already aware cjxl has a custom workaround for this for JPEGs only, and I am very much aware of the features listed in the specification, as I mentioned above.

All this time I’m talking about general support in the libjxl library that SW developers need to pick up and start using in 3rd party applications so this format gets wider adoption.

Since you like link sharing so much, here’s a couple more comments from the same person:

As of this moment, we’re not there yet, but will be soon.

Jon Sneyers Czerwony trójkąt skierowany w dół


17 gru 2021

The JPEG XL standard has now been formally approved: the Final Draft International Standard (FDIS) of ISO/IEC 18181-1 (the JPEG XL codestream spec) was approved unanimously; the International Standard will be published in January 2022. It’s done!


HDR Output (Technology Preview) 18 paź 2022


The new JPEG XL format offers several advantages over JPEG, including higher bit depth support and smaller file sizes, making it a great choice for HDR photos.

When the HDR Output feature is enabled, Camera Raw 15 supports opening and saving photos using JPEG XL. You can use JPEG XL for other types of photos as well.

and ?

RAW to jxl …


A few tidbits I found while trying to investigate using .jxl files

Although it seems to be supported in several versions of Firefox, as of the current FF 106, it really is not. There is a flag to enable jxl support in Firefox, but it does nothing. You have to use Firefox Nightly to actually be able to display jxls, using the flag.

jxl is also supposedly supported in ffmpeg as of version 5.1. I have that installed in Arch Linux, but it doesn’t actually work there, either. I asked for support, and the answer was that jxl is not made into the ffmpeg that is in the Arch repositories. (Well, why not?) I would have to make and compile it myself, or there is a git version in the AUR that I could install, which requires many other dependencies. Ugh!

Finally, Image Magick does support jxl. I can use Image Magick to convert other format files to jxl, and I can use it to display a jxl in a desktop window. That doesn’t help much for everyday use cases, but at least it works.

1 Like

And, just as more and more apps were beginning to support it, Google suddenly decided to kill it, citing some dubious reasons such as “not enough interest from the entire ecosystem” (I guess small companies like Facebook/Instagram, Adobe, Intel, Shopify, etc… don’t really count? Right?)


1 Like

Is this because they want to push webp?

Apparently they are working on WebP2 and use it as an image compression playground…

JXL seems like a good codec to standardize (compared to HEIC and even AVIF). Let’s hope with the pressure from people this can be circumvented somehow.

EDIT: also, there might be a push to adopt AVIF for convenience of AOM members, despite jxl being a bit better in certain scenarios (speed, quality, features).


I use windows binaries for the cjxl / djxl tools, and use them quite often.

On a few production websites where the content people upload insanely huge images, we store those images as JpegXL now.
The thing is, that those images never get served directly to web browsers. Depending on device and viewport, there is a smaller, cached version generated in the popular formats as webp/png/jpg, and that is what the browser receives.

But Jpeg XL for me is an archiving format (near-lossless / lossless 16bit). I never bothered to look at browser support to be honest. It looks that indeed, for both chrome and firefox, it’s required to enable a flag in the config (and yes, nightly).


  • The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default

Oh my g… really? It beats other formats in basically everything except lossless mode. It has higher bit depth modes from the start and supported as default (and only up to 16bit and more, not just 10/12 bit). It’s HDR ready from the start. It doesn’t degrade in quality by over smoothing the image when the bits get starved. And it compressed and decompresses in a fraction of the processing time compared to things like webp/heic/avif. And it’s standardised and bitstream locked.

This seems short sighted from the devs. I hope the ‘alternative chromium’ browsers keep it in.


Is this because they want to push webp?

Apparently they are working on WebP2 and use it as an image compression playground…

It looks like WepP2 also got the axe one month ago (“WebP 2 will not be released as an image format but is used as a playground for image compression experiments”):^!/

  • The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default

Yep, this is crazy… I am starting to wonder whether any of these next generation image formats will ever get widespread support in browsers.

I hope too, but unless some major industry player steps in and decides to maintain it, those forks probably won’t want to deal with an extra dependency (and the increased attack surface that comes with it).

1 Like

Yep. It’s a mind boggling argument by google.

But what is their plan then? just AVIF adoption?

1 Like

It seems Opera still supports it. I guess its down to just me and 7 other users worldwide :slight_smile:

1 Like

Google works in mysterious ways…

I hope they have a plan. But it is quite possible that they don’t care much about photo content. A good part of the discussion surrounding JXL seems to be around potential bandwidth savings, not high bit-depth/wide gamut/HDR (which in my opinion are its “killer features”). Maybe the cost/benefit ratio is not worth it to Google, who may not particularly care about high-quality photographic content.

On the other hand, maybe JXL can still have a more “niche” future outside the web, as some sort of TIFF replacement. If industry players like Adobe, open-source projects (and hopefully camera manufacturers at some point) keep pushing it, it might very well be the direction it’s headed. We’ll still need to convert to lower-bit-depth AVIF when publishing to the web but, then again, we already do that sort of lossy conversion when resizing to 1080px.

Opera is based on Chromium (like most browsers that are not Firefox or Safari), so unless the Opera developers decide to proactively maintain JXL support, it will likely get dropped.

1 Like

Exactly the opposite. Imagine the photo backup web storage savings Google would have if the phones switched to it.

Indeed! Not being myself a big fan of cloud backup, I had forgotten this probably-multi-billion-dollar business :sweat_smile:

This makes Google’s decision even less logical…

Could this be a hardware decoder thing? With AV1 decode maybe AVIF decode just comes “computationally free” (big air quotes! as in just en/decode on dedicated hardware) whereas jxl is not as straightforward to en/decode on specialized hardware?


This might be the only logical reason I have heard so far! (although it sucks for the web) If the cost of the encode/decode exceeds that of the bandwidth, then JXL may not be interesting for Google. But this is a bit surprising considering that Facebook and some cloud companies are backing it. How can their cost/benefit calculation be so different from Google’s?


Just look at history - for decades at this point, multiple attempts to unseat JPEG as the dominant format for image delivery have been made. ALL have failed.

The ONLY time we’ve seen ANY progress whatsoever in that fight has been by formats that leveraged commonality with widely supported video codecs. HEIC/HEIF/AVIF are literally just a single intra frame of one of the “big boy” video formats, in most cases even just recycling the container format of the video. HEIC is the first time in DECADES we’ve seen camera manufacturers support anything beyond JPEG and raw for stills, and no surprise, it’s because the market demands that they support H.265 video too, so once you’ve got that, why not just recycle the IP blocks for your stills output?

Some of the stated advantages of JXL (for example 16 bits vs. 10) don’t actually exist for JXL (HEVC also supports 16-bit 4:4:4 but it’s not commonly supported, AVIF can go up to 12-bit 4:4:4), and even if you just assume HEIC/AVIF limited to only 10-bit log encoding (such as PQ), the advantages of 16 bits are extremely questionably for last-mile end-user content delivery, any advantages as an archival/intermediary format aren’t really relevant to browser support. Browsers don’t natively support DNG or EXR either.

Even for software-only implementations, it’s “one library for video and stills” vs “library that only supports stills and is useless for video”.

Whether Facebook is using it for internal storage is irrelevant - companies like Facebook have enough volume in datacenter hardware that they can develop/require vendors to develop custom hardware solutions that aren’t seen in enduser systems. Application-specific hardware accelerators - Engineering at Meta - Facebook datacenters had Mount Shasta in 2019 and probably Shasta v2 supports JXL, end user hardware does not.


You really think there are that many Opera users? :wink: