Convert AVIF to ICO

Nobody draws a logo in AVIF. The file arrived because something converted it: a build step that runs over every image in an assets directory, a CMS that re-encodes uploads, a CDN that negotiates the format per request, or a right-click on a live site because the design files are three agencies ago.

That matters because you are working from a derivative. Whatever the pipeline did — a resize to the largest size the page needed, a lossy pass at whatever quality the config specified, a flattening onto a background — is baked in, and this conversion starts from that rather than from the artwork. It is a legitimate place to start, and it is worth ten minutes first to check whether the original is genuinely gone: a source repository, a brand folder, an old email from the designer, or the assets directory the build step reads from, which frequently still contains the thing the pipeline converted.

The two formats sit at opposite ends of the scale question. AVIF can hold an image 65,536 pixels on a side; an ICO stops at 256, and 256 is written into the header as a zero because the size field is a single byte and the real number will not fit in it.

So the decisive loss in this conversion is not compression — there is no quality setting on an ICO target, because each image inside the container is a lossless PNG and a slider would have nothing to act on. It is the reduction in scale, and between the two ceilings it can be a factor of 256. Everything the pipeline preserved above 256 pixels is discarded here, and there is no setting that keeps it, because the container has no room for it. The practical implication is that a very large source buys you nothing beyond a clean downscale: anything past about 512 pixels is being thrown away regardless, and the qualities that decide whether the icon works are all decided far below that.

An ICO is a container designed to carry a set: the same mark at 16, 32, 48 and 256 pixels, with the system picking whichever it needs rather than scaling one on the fly. What this conversion writes is that set. The "Icon sizes" control chooses it, the default is 16, 32 and 48, and each entry is a separate PNG made at its own size.

That removes the larger half of the problem — a browser drawing a 16-pixel tab no longer reduces a 256-pixel image with a general-purpose filter — and leaves the smaller half. The entries are resampled from your artwork, not redrawn for their size, so a one-pixel stroke reduced from 256 to 16 is still a grey smudge and the only fix is to draw a thicker one at that size. That is a job for an icon editor such as IcoFX or GIMP, and it is now a single substitution into a file that already has the right structure rather than a rebuild from nothing.

The image is not cropped. Every entry written here is square, and an oblong source is centred on it at the largest scale that fits with transparency filling the rest — nothing is stretched, which is the right default, but the mark ends up occupying a band across the middle of an icon whose neighbours fill theirs edge to edge. At 16 pixels a logo three times wider than it is tall gets five pixels of height.

So fix the framing in whatever will open the file — GIMP, Squoosh and ImageMagick all read AVIF — by cropping to the symbol rather than padding an already wide lock-up. What you want the converter to receive is a roughly square mark that fills its frame, because everything it does after that only makes the picture smaller. A little padding on all four sides is worth keeping even so, since an icon drawn hard to the edge looks larger and heavier than its neighbours in a row of tabs.

AVIF stores up to twelve bits per channel with a wide colour gamut. An ICO holds eight bits per channel, so that headroom goes.

This is the one place in the AVIF bundle where the reduction genuinely does not matter. A 32-pixel icon is 1,024 pixels in total, which is fewer than a single line of a modest photograph, and a favicon is drawn at the mercy of whatever colour management the browser chrome applies around it. If your icon depends on colour subtlety it will fail for reasons that have nothing to do with bit depth — the shape carries an icon and the palette decorates it, and at these sizes that ordering is absolute.

The alpha channel crosses over intact, and it carries more of the visual result than anything else here. A browser tab is a light strip in one theme and a dark one in the other, and an icon with real transparency looks right in both; one with a baked-in white square looks like a mistake in one of them.

If the AVIF was flattened somewhere upstream — pipelines do this when they also emit a JPEG fallback and treat every image the same way — the transparency is already gone and this conversion cannot bring it back. Check the corners of the source before converting by opening it over a dark background, because a white box is much easier to fix at the artwork stage than after it has shipped and been cached everywhere.

AVIF is a web delivery format and what the web mostly delivers is photographs, so the average file that lands on this page is the wrong material for an icon by a wide margin. At 16 pixels a photograph is a smear; at 32 it is a slightly larger smear.

What survives that size is one shape, high contrast, two or three colours: the initial rather than the wordmark, the symbol rather than the full lock-up. At 16 pixels a letterform is roughly ten pixels tall, which is enough for one character and not enough for a word, and any stroke thinner than the others disappears entirely. The test costs nothing — shrink the AVIF to 16 pixels in any viewer and look at it from a normal distance. If it is unrecognisable there, the problem is the artwork and no container will fix it.

If the vector still exists, use it. Both pages write the same sizes into the same container, so the difference is entirely in what the sizes are made from: an SVG is rendered to pixels here, once, at full icon resolution, while an AVIF arrives already carrying whatever the pipeline did to it.

The gap is visible at small sizes and it is not subtle. A vector rendered cleanly and then reduced to 16 keeps a hard edge; a lossy AVIF that was itself resized by a CDN has soft, ringing edges before this conversion starts, and reducing it further spreads them across two rows of pixels and halves the contrast. The AVIF route is the answer when the vector is genuinely unavailable, and it is worth one search through the repository before accepting that it is — an SVG favicon source is frequently sitting in the same directory the pipeline read from.

Put it at the root of the site as favicon.ico. Browsers have requested that path for nearly thirty years regardless of what the HTML declares, so a file there stops a stream of 404s in the access log and covers the feed readers, link previews and older tools that look nowhere else. It costs a few kilobytes and it is the one favicon placement that requires no markup at all.

Do not let the pipeline that produced your AVIF anywhere near that file. Content negotiation that swaps images for AVIF is exactly right for page content and wrong for the icon, because the request for /favicon.ico is often made by something that is not a modern browser at all. Serve the ICO as an ICO, and declare a PNG or SVG alongside it for browsers that will take one.

Drop up to 100 AVIF files at once and each becomes its own ICO, returned together as a ZIP. That fits the situation this page is written for, where a build step has already converted an entire icon directory and the whole set has to come back.

It all runs in your browser, so there is no upload, and the free tier’s 100 MB per file is never the constraint — icons are small enough that neither the ceiling nor the machine is what stops you. The constraint is whether each one reads at 16 pixels, and that is a question of artwork rather than of throughput. A batch is also the moment to be honest about how many icons a project needs: most sites want one mark done properly rather than a dozen variants, and a folder of forty is usually a sign that the assets directory is being converted instead of the icon.