Convert JXL to AVIF

Both formats exist because JPEG is thirty years old and the web moves a great many photographs. AVIF arrived first, in 2019, as a still image wrapped in the AV1 video codec and published by the Alliance for Open Media. JPEG XL followed in 2022 as ISO/IEC 18181-1, from the same committee that produced the original JPEG standard.

They are peers in a way this site's conversions rarely are. Both are open, both carry full alpha, both do lossless and lossy, both handle wide-gamut colour, both allow animation. The differences that matter to a working project are not in the compression tables — they are in which one a browser will decode, and that question was settled against JPEG XL in 2023 when Chrome removed its experimental support.

On lossy photographic compression the two trade places depending on the material and the target quality. AVIF tends to hold up better at aggressive settings, where its video heritage smooths what would otherwise be visible artefacts. JPEG XL tends to be ahead at high quality, where its finer-grained coding preserves texture that AVIF blurs into flatness.

On lossless there is no contest: JPEG XL was designed around it and can repack an existing JPG roughly twenty per cent smaller with the original bytes recoverable, which is a trick AVIF has no equivalent for and which is what made the format interesting to anyone holding a decade of camera output. If you are converting for the web, none of this is decisive; the difference between the two codecs is smaller than the difference between either of them and the JPG you were serving before. If you were converting for an archive, this section would be an argument against the conversion.

AVIF is a container and nothing else. The pixels inside are an AV1 keyframe, and the file around them is an ISO base media box structure — the same family of wrapper as MP4. JPEG XL is a codec first: the plain form of the file is a raw bitstream starting with the two bytes FF 0A, and the boxed form exists only so that metadata has somewhere to live.

The consequence is practical rather than academic. Browsers got AVIF nearly for free because they already had an AV1 decoder for video, and hardware decoding follows the same path on phones and newer laptops. JPEG XL has no video codec carrying it, so every platform that supports it had to choose to, and most did not. The shared lineage is visible in the file itself: an AVIF opens with the same ftyp box an MP4 does, and only the brand recorded inside it says which of the two you are holding.

On paper this pair keeps more than most: JPEG XL allows up to 32 bits per channel and AVIF up to 12, so a high-bit-depth original would survive the format change with room to spare. In this converter it does not, and the reason is worth stating rather than glossing.

The decode step returns 8-bit RGBA pixels and the AVIF encoder is handed that buffer, so the output is 8-bit regardless of what the source held. For web delivery that is the correct output anyway — browsers composite 8-bit and the extra depth would be discarded downstream. For a graded master or a file you intend to edit further, keep the JPEG XL and treat the AVIF as a copy.

Expect a real pause per file. AVIF encoding searches much harder for structure it can describe compactly than any still-image encoder of the previous generation, and a large photograph can take several seconds on a fast machine. Decoding the JPEG XL is quick by comparison; the time is spent entirely on the way out.

That shapes how to use this page. Converting three images is instant enough to feel interactive. Converting three hundred is a job to start and walk away from — which is exactly the case where a hosted service would be metering the processor time, and here it is your own machine and free. Batch progress is reported per file so a long run does not look stalled, and each file reports again between the decode and the encode, because the second half is where the seconds go.

AVIF carries a full alpha channel, so transparency needs no decision here — no fill colour, no matte, no halo where the edges were soft. Both formats also describe wide-gamut colour, which makes this the one delivery target that could in principle preserve a display-P3 original from a modern camera.

The caveat is the same as the depth one. This conversion writes no ICC profile into the output, so the result is untagged and every viewer will read it as sRGB. Where colour accuracy is the point rather than file size, that is a reason to keep the JPEG XL as the reference and to check the AVIF against it before publishing.

Both formats define animation, so this limit belongs to the converter rather than to either specification. The JPEG XL decoder returns one image, and that single frame is what the AVIF encoder receives — an animated source therefore produces a still, without an error and without a warning from the codec.

For actual motion the right answer is not an image format at all. An AV1 or H.264 video in an MP4 or WebM container will be smaller than an animated AVIF of the same clip, plays with hardware decoding almost everywhere, and can be paused. Use this conversion when you want a frame, not when you want the sequence.

Everything above points the same way. JPEG XL is the better container for the thing you keep — lossless mode, high bit depth, and the ability to repack an existing JPG without touching its image quality — while AVIF is the better container for the thing you serve, because it is the one that renders. Those are different jobs and there is no need to pick one file to do both.

In practice that means converting a copy of the library rather than converting it in place, and keeping the JPEG XL originals wherever the AVIFs are generated from. Formats keep arriving. The archive that still holds its masters can produce the next one in an afternoon; the archive that replaced them cannot. WebP, HEIC, AVIF and JPEG XL have each been described as the successor to JPEG within about a decade of one another, and the only durable strategy across that run has been to keep whichever file holds the most information.

The support argument for AVIF is a browser argument and it does not extend much past the browser. Desktop image viewers, phone galleries, chat clients, email software and plenty of content management upload forms still refuse it — the same list of failures that makes a JPEG XL awkward to send to someone, with a few more entries ticked off.

So do not treat this conversion as making the file portable. Do not email an AVIF, do not make it the copy a customer downloads, and do not assume a colleague can open one because their browser can display it. AVIF is a delivery format for web pages; where the file has to be opened by a person rather than rendered by a page, JPG or PNG is still the answer and always will be.

Drop the directory. Each file is decoded, optionally resized, and re-encoded locally, keeps its name with the extension changed, and the batch returns as one ZIP. Files up to 100 MB are accepted on the free tier and nothing is uploaded, which for a photographic archive is the difference between a conversion and a disclosure.

Because AVIF encoding is the expensive step, this is one of the pairs where running locally is faster in wall-clock terms than a hosted converter would be for anything beyond a handful of files — no upload of the source, no download of the result, and as many parallel files as the machine will carry.