Convert AVIF to GIF

Two different people arrive at this page and only one of them should stay. The first is facing a system whose accepted formats are JPG, PNG and GIF: a forum attachment box, a wiki uploader, an internal tool from before the last redesign, a signature block in an old mail client. For that person GIF is not a choice, it is the intersection of what they have and what the box will take.

The second came looking for an animation, and this is the wrong page for them. Nothing here turns a still picture into a moving one, and an AVIF that already moves does not stay moving through this conversion. If your destination will accept a PNG, use PNG instead — it is lossless, it keeps every colour, and it handles transparency properly. GIF is worth choosing only when something specifically refuses everything else.

AVIF can hold a sequence and GIF can hold a sequence, so on the specifications this looks like a conversion that should work. It does not. The engine decodes a single image and the GIF encoder writes a single frame, so an animated AVIF comes out as one still picture and the rest is gone.

It is said here in the second section rather than buried in a note because a converter that quietly delivers a tenth of a file is worse than one that refuses. If the thing genuinely has to keep moving, no image format on this site is the right answer: an MP4 built from whatever produced the animation is smaller than any animated image format at the same content and plays in everything, including the places GIF is being chosen for.

This is the defining loss of the pair. GIF is an indexed format with a palette of at most 256 entries, fixed by the GIF89a specification. AVIF describes up to twelve bits per channel and wide colour gamuts, which is millions of distinguishable colours in the ordinary case and considerably more in the unusual one. Everything in between has to be thrown away.

What that looks like depends entirely on the picture. A logo, a diagram, a screenshot of a form or a piece of flat artwork may have fewer than 256 colours to begin with and can come through almost untouched. A photograph cannot: skies band into visible steps, skin tones go blotchy, and smooth gradients turn into stripes. Banding on photographs is the failure mode this registry records against GIF, and it is not a bug to be tuned away. The irony is that gradients are exactly what AVIF is best at holding, so the pictures that survived the web most gracefully are the ones this conversion damages most.

Something has to decide which colours survive, and doing it badly is what makes bad GIFs. Rounding each channel to a fixed grid is the cheap approach and it produces exactly the posterised look people associate with the format. This converter uses gifenc, whose quantiser is a port of PnnQuant.js: it starts from the colours in the image and repeatedly merges the closest pair until 256 are left, so the surviving entries are the ones whose loss changes the picture least.

The palette is built from a slightly reduced colour space rather than the full one, which costs a little accuracy and saves seconds on a large photograph. For a format that ends at 256 colours the trade is heavily worth making. The result is not something anyone would call obviously degraded on ordinary content, and it is still a GIF: the ceiling is the format’s, not the encoder’s.

Fewer colours does not mean fewer bytes, and this is where the intuition fails. GIF compresses losslessly with a scheme from 1987 designed for flat graphics with runs of identical pixels. AVIF is a still frame of a 2019 video codec that spends real computation finding the most compact possible description of a picture.

So a photograph that was 180 KB as an AVIF can come back as a GIF several times that size, having lost most of its colours on the way. You pay twice — in fidelity and in bytes — and you get compatibility. That is a bad trade unless the compatibility is the thing you actually need, which is why the first section spends its time on who needs it.

The one case where the arithmetic is kinder is flat artwork with large areas of a single colour, which is what the 1987 scheme was built for. A diagram, a logo on a plain field or a screenshot of a mostly white page can compress well as a GIF and lose nothing visible, because it never had more than a couple of hundred colours to give up.

AVIF carries a full alpha channel: a pixel can be any degree of transparent, which is what makes antialiased edges and feathered shadows look right against any background. The GIF format offers one bit of that — a palette entry nominated as invisible — and the encoder on this page nominates none. Every pixel of the file you download is opaque.

So a cut-out is composited rather than translated. The transparent areas are painted with the background colour set above the drop zone, white unless you change it, and the picture is quantised afterwards, which means the feathered edge blends into that colour instead of hardening against it. Set the colour to the one the image will actually sit on and the result is clean. If the destination will take a PNG, the problem disappears entirely.

The places are specific and they are all old: forum software whose upload validator lists three extensions, wikis configured a decade ago, ticketing systems, learning platforms, email signature editors, embedded documentation viewers, internal tools nobody owns any more. GIF is read by every browser and by essentially every piece of image software ever written, which is the one thing it still has that AVIF does not.

The registry marks GIF as a legacy format, and legacy is exactly the right word — it is not current, and it is not going away, because the software that only knows it is not going away either. When you are on the wrong side of one of those uploaders, the format’s age is the asset and everything else on this page is the invoice.

The maximum width control resizes in the same pass that encodes, and using it is usually the right move here. Fewer pixels means fewer places for the palette reduction to be visible, and a GIF displayed at 600 pixels wide that was built at 600 pixels wide looks considerably better than one built at 3,000 and scaled down in the browser.

It also addresses the size problem from the section above, and it addresses it honestly: fewer pixels rather than a worse description of the same pixels. Resizing afterwards in another tool is the worse order, because it resamples an image that has already been reduced to 256 colours and smears the palette entries into intermediate values the file cannot hold.

PNG is the answer for almost everybody who lands here. It is lossless, it keeps every colour, it carries a real alpha channel, and it has been read by everything since the late nineties — so any system modern enough to have been configured this century will take one. The only cost is file size, and for a screenshot or a piece of artwork that cost is small.

JPG is the answer for a photograph headed somewhere that wants a small file and does not need transparency. WebP is the answer if the blocker is a toolchain rather than an era. GIF is the answer when the accepted list literally says GIF and nothing else, and reading this far to confirm that is a better use of five minutes than converting first and looking at the result afterwards.

Both halves run in the browser tab on your own processor: jSquash decodes the AVIF, gifenc quantises and writes the GIF, and no part of the file is uploaded. There is no account, no queue and no daily allowance, and the free ceiling is 100 MB per file, which no web-delivered AVIF will approach.

That also makes this work on a machine that cannot open the source at all. If double-clicking the AVIF does nothing because the operating system has never heard of it, the browser is still the one piece of software that reads it, and the conversion happens inside the browser. A folder of AVIFs converts in a single pass and comes back as one ZIP with per-file progress.