Convert ICO to AVIF

AVIF is not an image format that happens to compress well; it is the intra-frame path of the AV1 video codec with a container around it. Everything it is good at follows from that. AV1 was built to predict the contents of a block from its neighbours and to discard the residual detail a moving eye will not catch, which is an extraordinarily effective strategy on photographs and on film grain.

An icon has neither. It is a small number of flat regions with hard boundaries and a few dozen antialiased pixels along each edge. There is no texture to model, no gradient to predict and very little residual to throw away — so the machinery that makes AVIF win on a photograph has almost nothing to do, while its fixed overheads remain.

On a test icon of 8,471 bytes holding four entries, converted at the default quality of 82, the results were: 1,737 bytes as PNG, 1,894 as GIF, 3,054 as WebP, 3,624 as AVIF and 4,005 as JPEG. The order is almost exactly the reverse of the one the same test on a photograph would give.

That is not a marginal difference. The AVIF is more than twice the PNG and it is the lossy one. For a directory of two hundred icons, migrating them to AVIF adds roughly 380 kilobytes to what the site ships rather than removing anything. Carve the icons out of the migration and keep them as PNG.

Transparency is preserved: on the test icon the corner pixel of the resulting AVIF reads 0,0,0,0. That is not a given for every efficient format — the GIF path on this site turns the same corner opaque black — so if the mark is a cut-out and the format has to be AVIF, at least this part works.

It works by coding the alpha as a second plane alongside the colour, effectively a second small image inside the container. On a photograph that overhead is lost in the noise. On a 256-pixel icon, where the whole file is a few kilobytes, it is a visible share of the total and part of why the number above is what it is.

The AVIF encoder is the largest WebAssembly module this site ships and the slowest to run, because encoding a still AVIF means running an AV1 intra-frame search. For one file it is a pause. For a folder of two hundred icons converted in one go it is a genuine wait, and it is your own processor doing it rather than a server.

This is worth weighing against the byte result rather than separately from it. Spending real encode time, on every build, to make each icon twice as large is a poor trade in both directions at once.

An ICO holds the same mark at several sizes and an AVIF holds one picture, so something has to choose. Your browser’s icon decoder does, and it returns the largest entry — verified by building a file with 16, 32, 48 and 256 pixel drawings in four different colours and converting it with the directory written in three different orders.

The ceiling is 256 pixels, set by the ICO format rather than by AVIF, which reaches 65,536. So the input to the encoder is always a small image, which is the condition under which every efficient format performs worst relative to PNG.

AVIF can store twelve bits per channel and a wide colour gamut, which is one of its genuine advantages over WebP and JPEG for photography and for high-dynamic-range material. An icon file stores eight bits per channel in a standard gamut and always has.

So this capability is available and unused. It costs nothing directly, but it is a fair summary of the pair: almost everything AVIF is better at is something an icon does not have. The one property it brings that matters here — alpha — is one PNG already had.

Every current major browser decodes AVIF, and has for several years. That is enough for most sites to serve it directly. It is newer than WebP, so the tail of clients that cannot read it is longer, and the usual answer is a picture element with a fallback source rather than a straight replacement.

Note what that means for an icon: you now ship two files instead of one, and the fallback is the PNG that was smaller in the first place. The complexity is real and the saving is negative.

A blanket rule is attractive because it removes a decision from every future build, and blanket rules about image formats are usually right. This is the case where one is not. Split the rule by content rather than by directory: photographs and screenshots to AVIF, flat artwork and icons to PNG, and write the reason next to the rule so the next person does not "fix" it.

If the pipeline genuinely cannot express two rules — some CDN transforms cannot — then converting the icons is a defensible cost of uniformity. Know that it is a cost, and know roughly how large: a couple of kilobytes per icon, in the wrong direction.

Drop the folder. Every file is decoded and encoded on its own and the results return as a ZIP, with one quality setting across the batch. Expect it to take noticeably longer than the same batch to PNG or WebP, for the reason above.

The dimensions will not be uniform unless the source set was. Icon collections mix files that carry a 256-pixel entry with files that stop at 32, and since the encoder’s fixed overheads matter more the smaller the image, the 32-pixel members of the set are where AVIF compares worst of all.

Two things are worth looking at, and neither takes long. The first is the byte count of both files side by side, because that is the number the migration was undertaken for and it is the one most likely to be assumed rather than measured. The second is the mark itself at the size it will actually be displayed — not zoomed in, where lossy artefacts look alarming and nobody will ever see them, and not as a thumbnail, where everything looks fine.

Keep the original icon file either way. It is the only thing that still holds the small hand-drawn entries, it is a few kilobytes, and it is what a browser will keep requesting from the root of the site regardless of what the build produces.