Convert JXL to GIF

There is one good reason and it is external: the place the image has to go accepts GIF and refuses everything else. Old forum software, internal tools written a decade ago, some ticketing systems, a few email signature editors and a surprising number of embedded web interfaces are all in that category, and no argument about codecs helps you against an upload validator.

If your destination will take anything else, take anything else. WebP is smaller, keeps full colour and real transparency and is read by every browser; PNG is the lossless option where the receiving system is old but not ancient. This page is written for the constrained case, and being honest about that is more useful than pretending GIF is a reasonable target for a JPEG XL.

GIF stores an indexed image: every pixel is a number pointing into a palette of at most 256 entries, and that limit is in the GIF89a specification rather than in any setting. JPEG XL comes from the opposite end — up to 32 bits per channel, wide-gamut colour, and no palette anywhere in the design.

On a photograph the collapse is visible immediately. A sky that ran through two hundred shades of blue gets a dozen, and the boundaries between them become bands rather than gradients. Flat material survives far better: a diagram, a screenshot of an interface, a logo on a plain background may use fewer than 256 distinct colours already and convert with no visible loss at all. If your JPEG XL is a screenshot of a form or a chart with six colours in it, none of the warnings on this page will apply to you.

GIF was published by CompuServe in 1987 and its current revision, GIF89a, dates from 1989. It predates the web, colour management, alpha channels as they are now understood, and every assumption a modern codec makes. JPEG XL was standardised in 2021 as ISO/IEC 18181 by the committee that wrote the original JPEG specification.

Thirty-four years separate them and it is not a gap that compression cleverness closes. The formats do not overlap in intent at any point: one was designed to move small graphics over a dial-up connection, the other to store photographs at archival quality. Everything on this page follows from that mismatch, and no converter can argue a photograph into a palette of 256 entries without something visible happening to it.

This is the part people do not expect from a format with 256 colours. Before compression, a paletted image is one byte per pixel, so a 12-megapixel photograph is twelve million bytes of palette indexes. GIF then applies LZW, which finds runs of repeated values — abundant in flat graphics, almost absent in photographic noise.

The result is that a JPEG XL of two or three megabytes routinely becomes a GIF several times that size while looking substantially worse. If file size is any part of your reason for converting, stop here: this pair moves in the wrong direction on size and on quality at once, which is unusual even among lossy conversions. The one exception is the flat-graphic case: a diagram with large areas of a single colour is exactly what LZW was built for, and there a GIF can be genuinely small.

GIF transparency is a single palette entry flagged as invisible, with no in-between value for the row of half-transparent pixels that makes a cut-out edge look smooth. The encoder here goes one step further and flags no entry at all, so nothing in the GIF is transparent: the alpha channel is resolved before the palette is chosen, by filling the see-through areas with the background colour set above the drop zone.

That makes the result depend on one decision. Set the colour to the one the image will sit on and the anti-aliased edge blends into it exactly as it did in the JPEG XL; leave it at white over a dark page and the cut-out arrives inside a white rectangle. Where the transparency is the reason the image exists — a logo that has to work on backgrounds you do not control — WebP or PNG is the target that keeps it and GIF is the one that resolves it for you.

Both formats can hold animation, which makes this a limit of the converter rather than of GIF. The JPEG XL decoder used here returns a single image, so an animated source yields a one-frame GIF with the remaining frames dropped by the codec before anything on this page sees them.

That is worth knowing before you start, because a still GIF is exactly the file nobody wants. If the sequence is the point, MP4 or WebM is both the correct format and a far smaller one — an animation that runs to several megabytes as a GIF is typically a tenth of that as video, and it plays with hardware decoding on any phone. The systems that still insist on GIF are usually the same ones that will not accept a video file either, which is worth establishing before you spend an evening on the conversion.

Something has to decide which 256 colours survive, and doing it badly is what produces the banded, posterised GIFs the format is remembered for. The converter builds the palette from the image itself, clustering the colours that actually appear rather than rounding each channel to a fixed grid, which is the same family of approach ImageMagick uses.

The palette is built in a reduced colour space to keep the work fast, which costs a little accuracy on subtle gradients in exchange for not spending several seconds on a large photograph. For a format that ends at 256 colours the trade is heavily worth making: the quantisation step, not the arithmetic precision inside it, is what dominates the result.

GIF has no quality parameter, which is why no quality setting is offered here at all. There is no rate to trade against detail the way there is in WebP or AVIF — the file is exactly as large as the palette indexes and the LZW dictionary make it, and the only lever with any effect on either is the number of pixels.

That makes the maximum-width control the one setting worth touching here. Halving the width of an image quarters the pixel count and therefore roughly quarters the GIF, and on a destination that only accepts GIF there is usually a size limit attached as well. Resize first, convert second, and check the result at the size it will actually be displayed at. GIF itself allows up to 65,535 pixels on a side, so the ceiling you hit will always be the destination's rather than the format's.

JPEG XL carries EXIF, XMP and an ICC profile. GIF has nowhere to put any of them — no standard metadata block, no colour management, no capture information. The camera, the lens, the date, the coordinates and the colour space all end at this conversion, and there is no option that would keep them.

Whether that is a loss or a feature depends on why you are converting. Posting to a public forum, it is the outcome you would have asked for, and it is one fewer thing to remember to strip. Filing the same image as a record, it means the GIF is not the copy to file: the JPEG XL is, because it is the only one of the two that still knows where the picture came from.

The decode, the palette build and the GIF write all run in your browser, so nothing is uploaded and there is no per-file wait. Files up to 100 MB are accepted on the free tier, and a folder of JPEG XL files converts in one pass and comes back as a ZIP.

Keep the JPEG XL. This is the most lossy conversion in the set — colour, transparency, animation and often size all move the wrong way — and there is no route back from the GIF to what the original held. If the constrained system ever accepts a modern format, you want to still have the file to give it, and a second conversion from the master costs you nothing but the drop.