Convert ICO to WebP

An ICO exists to answer a question the operating system asks: give me this mark at the size I need right now. It answers it by storing several drawings in one file with a directory at the front. A WebP answers no such question — it is one picture, at one size, meant to be placed by a stylesheet.

So the conversion is a change of role as much as of format. What you get is an image asset that behaves like every other image on the page: it can be given a width, put in a srcset, cached with a fingerprinted name. What you give up is the operating system’s ability to pick a size for you, which on a web page it was never doing anyway.

WebP carries a full eight-bit alpha channel, so a cut-out mark, a rounded tile or a soft shadow arrives intact and drops onto whatever background the page has. On a test icon the corner pixel of the resulting WebP reads 0,0,0,0. The file written is the extended VP8X form, which is what makes room for the alpha data alongside the colour.

That single property rules out JPEG for this job entirely, and it is worth saying because the two formats are otherwise close relatives in how they compress. If the icon has no transparent pixels at all — a square tile with a solid background — the argument is much weaker and either would do.

The quality setting starts at 82, which is a sensible middle for a photograph and a little low for artwork made of flat fills and hard boundaries. Lossy compression works by discarding detail the eye is unlikely to miss, and on a photograph that detail is texture. On an icon it is the edge of a letterform.

At 256 pixels the whole file is a few kilobytes, so there is almost nothing to defend by keeping the quality down. Push it towards 95 or higher and the outlines stay crisp for a cost measured in single-digit kilobytes.

The usual case for WebP is that it produces roughly a quarter to a third fewer bytes than the alternative at equivalent quality. That case is built on photographs, and it does not carry over to small flat artwork, where PNG’s combination of filtering and run-length compression is extremely hard to improve on.

Measured on the same 256-pixel test icon: 3,054 bytes as WebP against 1,737 bytes as PNG — the WebP is roughly three quarters larger and it is the lossy one. If the reason for this conversion was to save bandwidth, it is not going to. If the reason is that the build pipeline emits WebP and the icon needs to match, that is a good reason and the few kilobytes do not matter.

Your browser decodes the icon and returns its largest entry, which is what gets encoded. That was checked by constructing a file with 16, 32, 48 and 256 pixel drawings in four distinct colours and converting it with the directory in three different orders — the 256-pixel drawing came out every time.

The ceiling is 256 pixels and it belongs to the ICO format: an entry stores its width in a single byte, with zero standing in for 256. WebP itself reaches 16,383 pixels, so nothing on the target side is limiting you. If you need a larger image, the icon file is not where it lives.

The most common disappointment with this conversion is a mark that looks fine as a browser tab and blurry in a 200-pixel header slot. That is not the encoder; it is that the icon was drawn for tabs. Small icon entries are often redrawn rather than scaled — strokes aligned to whole pixels, detail removed — so enlarging one gives you a simplified drawing at low resolution.

Check the pixel dimensions of the result before you place it. If it is 32 pixels, the honest options are to display it at 32 or to go and find the original artwork; the maximum-width setting here only ever shrinks, and no converter can add detail that was never stored.

Consistency is a real engineering benefit even when the byte count is not. A site that serves one format for every raster asset has one cache policy, one build step, one set of content negotiation rules and one thing to test. Adding a PNG exception for six icons costs more in complexity than it saves in kilobytes.

The other genuine case is a large icon set. Sixty integration tiles at three kilobytes each is 180 kilobytes, and if they load together the difference against the PNG equivalent is measurable — but note that in that comparison PNG is ahead, so the reason to standardise is the pipeline, not the arithmetic.

Converting does not mean deleting. Browsers still request /favicon.ico from the root of every site whatever the HTML declares, so keep the original where it is and treat the WebP as a separate asset with a different job. They are not two versions of one file; they are two files that happen to show the same mark.

In the markup, the WebP goes in an img or a picture element like any other image, and the icon stays in a link element in the head. Mixing the two — pointing a favicon link at a WebP — works in current browsers and fails in enough tooling that it is not worth the saving.

Drop the whole folder and each file is decoded and encoded on its own, with the results returned as a ZIP. The quality setting applies to all of them, which is what you want for a grid of tiles where a single softer entry would be more noticeable than any of them being slightly imperfect.

The dimensions will not be uniform unless the source set was. Icon collections assembled over years mix files that carry a 256-pixel entry with files that stop at 32, and the WebPs inherit that spread with no warning — worth checking in the ZIP before wiring them into a layout that assumes one size.