Convert GIF to AVIF

A GIF frame is a grid of indices into a palette that holds at most 256 entries, compressed with LZW. It has no continuous tone in it at all. Whatever photograph, gradient or soft shadow the image began as was mapped onto those 256 values at the moment the GIF was written, and the mapping is not reversible.

This matters because AVIF’s reputation was earned on photographs, where it routinely beats JPEG by a wide margin at the same visible quality. A GIF is not a photograph in the relevant sense even when it depicts one, and the numbers people quote for AVIF do not transfer to this source. What is achievable here is bounded by what the GIF kept.

To fake the colours it does not have, a GIF encoder scatters pixels of two available colours in an alternating pattern — Floyd–Steinberg dithering, usually — so that the eye averages them into a third. At normal viewing size it works. At the pixel level it is a field of high-frequency noise.

Every modern image codec, AVIF included, works by predicting each block from what came before it and storing only the error. A dither pattern is precisely the thing that cannot be predicted, so the encoder is forced to spend real bytes recording it. The result is the counterintuitive outcome people report: an AVIF larger than the GIF it came from, on an image with six visible colours in it.

The quality control runs from 1 to 100 and defaults to 82, which is a sensible starting point for photographs and a conservative one here. A source with 256 colours has less to protect, and dropping to 60 or 65 on a converted GIF is usually indistinguishable from the original while removing most of the dither penalty.

The test that settles it is the byte count rather than an opinion. Convert once at the default, once lower, and compare the result against the GIF; if the AVIF is not comfortably smaller, the source is dithered and the quality number is the lever. On genuinely flat artwork — a logo, a diagram, an interface screenshot without gradients — even low settings hold up, because there is nothing subtle to damage.

The format’s browser support is recorded here as modern rather than universal, which is a meaningful distinction on a site with real traffic: current browsers read AVIF, and there is a tail that does not. A GIF, whatever else is wrong with it, is read by everything ever built.

So replacing the GIF outright is a regression for that tail, and the picture element exists for exactly this. List the AVIF as the first source, a PNG or WebP as the second, and leave an image element inside as the base case. The browser takes the first thing it understands and nobody sees a broken image — and it is worth checking the fallback actually renders, because the failure is invisible on the machine you built it on.

AVIF supports animation — the format record says so, and animated AVIF files exist. This conversion does not produce one. The decoder hands over a single picture and a single image is encoded, so an animated GIF becomes the frame it opens on.

That is the correct behaviour for the job this page is for, which is stills. If the GIF you are optimising does animate, converting it to AVIF is not where the saving is: a video container with real motion compensation will be a fraction of the size of any per-frame image format, animated AVIF included, and the video route is the one to take.

AVIF stores up to 12 bits per channel and can carry wide-gamut colour. Those capabilities are why it is a good archival and delivery format for photographs taken on modern equipment.

None of it applies to a GIF. The source has 8-bit indexed colour drawn from a table of 256 entries, and encoding it into a container that could have held far more does not create additional colours — it stores the same handful with room to spare. Nothing is lost either, which is the point worth taking away: the conversion is neutral on colour and the question is only about bytes.

AVIF’s known problem in this registry is encoding speed, and it is not a small effect. AV1 was designed with a large search space and the still-image encoder uses it; a single moderate image takes noticeably longer than the same image as WebP or JPEG, and it is doing that work on your own processor rather than on a server farm.

For a folder of legacy graphics that is still the right trade, because the cost is paid once and the saving is paid on every page load. But plan for it: a batch of two hundred old GIFs is a coffee break rather than a click, and running it on the machine that is also serving your development environment will make both feel slow.

AVIF is not automatically the right answer for a legacy GIF. WebP encodes far faster, is supported by a wider set of browsers, and on small flat graphics — which is what most surviving GIFs are — the file size difference between the two is often a few hundred bytes.

The rough division: AVIF where the image is large and photographic and the saving is measured in tens of kilobytes; WebP where the image is a small interface graphic and the win is compatibility and encode time. Where the GIF is a hard-edged logo with a handful of colours, PNG frequently beats both, because lossless compression of flat colour is what PNG was built for.

The AV1 encoder is a WebAssembly module downloaded the first time this pair is used and then run locally. The image is decoded and re-encoded inside the tab, so no part of it reaches a server, there is no account, and there is no per-file limit beyond the 100 MB free ceiling.

Running a whole folder works the same way and returns the results together. Because the work is local, the batch is bounded by your own processor rather than by a queue, which is the trade that makes a slow encoder acceptable.