Convert GIF to JXL

JPEG XL’s recorded uses here are archival and photography, and its status is niche. That combination is the honest description: it is a technically strong format with a small installed base, which makes it a candidate for a private collection and a poor candidate for anything that leaves your machine.

That is the reverse of the case for AVIF, which exists to be delivered over the web to browsers that support it. If the reason you are converting these GIFs is page weight, this is the wrong page — the delivery formats are. If the reason is that a folder of 1990s graphics is sitting on a disk and you want it in something modern, read on.

JPEG XL was standardised in 2021 as ISO/IEC 18181, aimed squarely at photographs: up to 32 bits per channel, wide colour, high-quality lossy compression that degrades gracefully, and the ability to re-encode an existing JPEG losslessly and smaller. Almost all of its advantages are about continuous-tone imagery.

A GIF has no continuous tone. It is 8-bit indexed colour with at most 256 entries, and it was written that way years ago. Feeding it to a photographic codec is not wrong, but it exercises none of the strengths the format is chosen for, and the size result is closer to a coin toss than the format’s reputation would suggest.

The conversion offers a quality number from 1 to 100, defaulting to 82. There is no lossless checkbox, and the encoder is driven through the same interface every other lossy target on this site uses. What comes out is therefore a re-encoding: close to the source at high settings, not identical to it.

For an archive that distinction is the whole question. Storing a lossy re-encoding of a picture that was already reduced to 256 colours means two generations of loss on an object whose value is that it is the original. If the aim is preservation rather than tidiness, either raise the quality to the top of the range and accept a larger file, or use a format where the answer is not a setting at all.

PNG compresses losslessly, keeps an alpha channel, opens in literally everything, and was designed for exactly this material — flat colour, sharp edges, limited palettes. On a typical surviving GIF it will land close to the JXL in size and it will be bit-exact.

The case where JPEG XL genuinely wins is a GIF that depicts a photograph: a heavily dithered scan or a screenshot of a photograph, where the palette reduction produced something noisy and PNG’s lossless compression has nothing to grip. There, a lossy modern codec at a sensible quality is smaller by a real margin. That is a minority of GIFs, and it is worth checking which kind you have before converting several hundred.

The format’s recorded problem is patchy support, and it is the risk that matters for the use this page is about. An archive is a bet on being able to open the files later, and JPEG XL’s position in browsers has been contested rather than settled since it was standardised.

The mitigation is not complicated: do not delete the originals until the collection has been readable for long enough to trust, and keep the format decision reversible. A folder of GIFs and a folder of JXLs costs disk space, which is the cheapest thing in this trade. A folder of JXLs alone, five years from now, is a bet.

Encoding JPEG XL here does not depend on the browser supporting the format. The codec is a WebAssembly module the page downloads and runs, so a browser with no JPEG XL support at all will still produce a valid file.

The visible consequence is that the result cannot be previewed the way a PNG or WebP conversion can. You download a file you cannot open in the tab you made it in, and checking it means opening it in GIMP, in ImageMagick or in a desktop viewer that supports it. Worth doing on the first file before committing a batch.

A GIF can nominate one palette entry as transparent, and JPEG XL carries a full alpha channel, so that transparency survives the conversion. What it cannot do is soften it — the source has hard on-or-off transparency and the result records exactly that, jagged edges included.

Animation is the loss. JPEG XL can store animation and this conversion does not produce it: one frame in, one image out. For an archive of animated GIFs the correct answer is to keep the GIFs, or to convert them to video, where a real codec makes them a fraction of the size instead of a fraction of the content.

GIMP reads and writes it. ImageMagick reads and writes it, which also makes it scriptable for anything you want to do to the collection later. Several desktop image viewers have added support, and operating system thumbnail support is uneven.

What that list does not include is a guarantee that a colleague, a client or a web form will accept one. If any of the files in this collection might need to be sent to somebody, keep a copy in a format that never needs explaining, and treat the JXL as the storage copy rather than the only copy.

A folder of files is dropped in one go and each is encoded in turn, in the browser, with the results returned together. The encoder is downloaded once and reused, so the cost of the WebAssembly module is paid on the first file rather than on every one.

Nothing is uploaded and there is no account, which for a personal image collection is usually the reason to do this locally rather than with an online service. The free ceiling is 100 MB per file, which no still GIF has ever approached.