Convert AVIF to JXL

Run this when something specifically requires JPEG XL. A tool that reads nothing else, a pipeline built around it, an archive policy that names the ISO standard, or a genuine experiment you intend to measure. Those are real reasons and this conversion serves them properly.

If the reason is that JPEG XL sounds newer or better, keep the AVIF. The two formats are close enough in compression that neither will surprise you, the conversion costs a lossy generation, and AVIF is the one every current browser reads while JPEG XL is still only partially supported. There is no scenario in which converting a working web image to JXL improves the page it sits on. Being talked out of a conversion is a legitimate outcome of reading a page about it, and it is the outcome for most people who land here.

AVIF was published in 2019 by the Alliance for Open Media, built on the AV1 video codec. JPEG XL followed in 2022 from the JPEG committee itself as ISO/IEC 18181-1, technically ambitious and in several respects the more elegant design.

Adoption did not follow the merits. Browser support for AVIF is now general across current versions; for JPEG XL it remains partial, which is why the format sits in the niche category rather than the current one, and why the demand for it is a fraction of the demand for AVIF. That gap is the single most important input into whether this conversion makes sense for your file, and it has nothing to do with which codec is better. It is also unlikely to change quickly, since the argument for a second modern format weakens every year the first one is already deployed.

The AVIF is decoded to raw pixels and those pixels are encoded again by the JPEG XL encoder. Nothing is carried across in its compressed form, so whatever the AVIF encoder discarded stays discarded and the JXL encoder then makes its own decisions on top of that.

At the default quality of 82 the second pass is rarely visible on a photograph, and it is not free either. Fine texture, film grain and the faint blocking that lossy AVIF leaves around hard edges are exactly what a second encoder handles worst, because it spends bits describing the first encoder’s mistakes as though they were part of the subject. If you intend to keep only one of the two files, that is a straightforward argument for keeping the one that has been encoded once — and if you are converting a library, it is an argument for finding the originals first.

On paper it goes further than AVIF in several directions that matter to photographers and archivists. It handles up to thirty-two bits per channel where AVIF stops at twelve, it is built for wide gamut work, and it was designed with long-term storage of large photographic collections as an explicit goal rather than as a side effect of a video codec.

Little of that reaches you through this particular conversion. What arrives at the encoder has already been through the browser image pipeline at eight bits per channel, so the depth headroom is theoretical here and would be theoretical from any web-delivered source, which never had more than eight bits to give. The place to exercise it is a conversion from a raw or sixteen-bit original in a desktop application such as GIMP or ImageMagick, not a re-encode of a delivery file. Knowing that a format can do something is not the same as being in a position to use it.

The strongest practical argument for JPEG XL is that it can take an existing JPEG and repack it roughly twenty per cent smaller with the image data itself untouched and fully recoverable. That is a genuinely rare thing in image formats and it is why large photo archives take the format seriously.

It works because the JPEG data is being rearranged rather than re-encoded, and an AVIF contains AV1 data instead — a completely different representation of the picture, with nothing in common with a JPEG beyond the fact that both are compressed. There is nothing to repack, so this pair gets none of that benefit and is a plain decode and re-encode like any other. If you have JPEG originals somewhere as well as AVIF derivatives, they are the interesting files for JPEG XL, and converting those is a materially better use of an afternoon than converting these.

GIMP and ImageMagick read JPEG XL, and both also read AVIF, which is a fair summary of the desktop situation: the tools that support one generally support the other, so the conversion rarely solves a "cannot open this" problem.

Beyond that the ground gets thin quickly. Operating system previews, older editors, upload forms, chat clients and print services frequently handle neither format, and where they handle one it is more often AVIF, because a browser engine is embedded in a great deal of software that is not a browser. If the goal is a file somebody else can open without a conversation about it, both of these are the wrong answer, and the page you want is the one that produces a JPG, a PNG or a PDF.

A picture element with a JXL source and an AVIF or JPEG fallback is the correct way to serve the format, and it works. What it does not do is save you anything, because the fallback has to exist and be generated anyway.

That is the awkward arithmetic of this direction for anyone doing it for web performance. You started with one format that reaches everyone at a size close to the best available, and you finish with two files, a negotiation and a cache that has to store both. The saving on the visitors who get the JXL has to pay for all of that, and on a format with partial support it usually does not. For a delivery image, AVIF is where the argument already ended.

The default of 82 is a sensible balance for a photograph and is the number to leave alone unless you have a reason. Raising it towards 95 makes the second encoding pass conservative, which is what you want when the file is going to be edited or re-encoded again afterwards.

Dropping it below 70 is rarely worth it on this pair. The source is already compressed, so the artefacts of the first encoder and the second one land on the same edges and compound faster than they would from an original, and the file gets visibly worse sooner than the number suggests it should. If the target size is aggressive, resizing the image is the better lever: fewer pixels at a decent quality beats the same pixels at a poor one, and it is the one change whose effect you can predict before running it.

Both formats can carry EXIF, XMP and an ICC profile, and neither block survives this route. Every image conversion here decodes to raw pixels and writes a new file from them, so the capture date, the camera and any coordinates are dropped rather than migrated.

For a file being handed to someone that is a privacy improvement and one fewer step to remember, since the coordinates of where a photograph was taken are the thing people most often forget to remove. For a photographer re-encoding a collection it is a serious loss: the capture time is what orders a library, and a folder of images that all claim to have been created today is close to useless. The honest conclusion is that a browser converter is the wrong tool for a library migration, and a desktop application that carries the tags across is the right one.

Drop a folder and the files convert one after another on your own processor, returning as a single ZIP with nothing uploaded and no daily allowance. JPEG XL encoding is quick enough that a large batch is a matter of patience rather than a blocked afternoon.

Keep the AVIF files. They are the earlier generation, they are the ones that will still display in a browser in five years, and re-running this conversion later costs nothing if the JXL copies turn out to be the ones you did not need. Deleting the source to save space on a pair of formats this close in size is the one mistake here that cannot be undone.