Convert SVG to ICO

Most icon conversions start from something that has already been rendered once — a PNG export, a screenshot, a JPEG somebody found. Each of those carries the resolution and the artefacts of whatever produced it, and scaling one down to icon size compounds them. An SVG carries none: it is instructions, so the renderer draws the mark fresh at exactly the size the icon needs.

That means the edges are antialiased once rather than twice, curves are computed rather than resampled, and there is no soft halo from a previous export. If you have the vector, use it. This is one of the few conversions where the choice of source genuinely shows in the result.

An ICO is a container built to hold the same mark at several sizes, so that Windows can show a crisp 16-pixel version in a taskbar and a crisp 256-pixel version on the desktop without scaling either. That is what the file written here does: the "Icon sizes" control decides the set, the default is 16, 32 and 48, and each one is a separate PNG with its alpha channel intact. Choose "All common sizes" and 64, 128 and 256 join them; choose "256 px only" and you get the single large entry instead.

Two hundred and fifty-six is the format’s own ceiling, not a choice made here. An entry records its width in a single byte, which stops at 255, so the specification reserves the value zero to mean 256 — and that is the byte written for a full-size icon. Nothing anywhere holds a larger one. The entries are written largest first, because a decoder that ignores the directory tends to take whichever it meets first and the largest is the least bad thing to hand it.

With the default set, it does not scale anything: it reads the directory, finds an entry that is already 16 pixels, and draws that. That is the difference the container was invented for, and it is visible — a 256-pixel image reduced on the fly by a browser’s general-purpose filter loses every alignment that made the mark crisp, while a 16-pixel entry was reduced once, in a filtered pass, before the file was written. Pick "256 px only" and the browser is back to doing the scaling itself.

What neither arrangement can do is redraw the mark. The 16-pixel entry here is the 256-pixel render reduced, not the SVG re-rendered at 16 with its strokes snapped to the pixel grid, so a one-pixel stroke still softens and a counter inside a letter still fills in. For a solid shape, a bold single letter or a strong silhouette that is fine. For fine detail it is not, which is why serious icon sets still contain a hand-drawn 16 — GIMP and IcoFX both let you add one to the file this page gives you.

The constraint is brutal and it is worth designing to rather than fighting. Sixteen by sixteen is 256 pixels in total, which is fewer than the characters in this sentence. Anything that needs more than about three distinct shapes to read will not read.

The usual moves: drop the wordmark entirely and keep the symbol, thicken strokes so they land on whole pixels, increase the contrast against both light and dark backgrounds, and remove any detail smaller than a tenth of the width. Because you are starting from a vector, making that simplified variant is a matter of hiding a few layers and exporting a second SVG.

The image inside the icon is a PNG, so the alpha channel comes through the whole chain: resvg renders the drawing onto nothing, the pixels keep their transparency, and the PNG stores it. A rounded mark keeps its rounded corners instead of gaining a white square.

This matters more than it used to. Browsers now render tab strips in a light or a dark theme depending on the operating system, and a favicon with a baked-in white background announces itself on a dark one. Leave the background out of the drawing and let the alpha do its job.

Modern browsers accept an SVG favicon directly, and it is strictly better where it is supported: one small file, sharp at every size, and it can respond to a dark colour scheme with a media query inside the drawing itself. The usual arrangement now is an SVG declared in the markup and an ICO sitting at the root for everything else.

That is not a reason to skip the icon. The request for /favicon.ico is made by browsers regardless of what the HTML says, and by a long tail of feed readers, link previewers and crawlers that parse no HTML at all. Both files, a few kilobytes together, and the question never comes up again.

Put the file at the root as favicon.ico. That single placement satisfies the automatic request and requires no markup at all — which is why it survived thirty years of the web changing around it.

Then declare the rest explicitly: a link element with rel="icon" and type="image/svg+xml" for the SVG, and an apple-touch-icon PNG at 180 pixels for iOS, which ignores both of the others. Three files covers every current client, and the icon is the one that needs no declaration.

Favicons are cached with unusual determination, in a store separate from the ordinary page cache, and a hard reload frequently does not clear it. This produces a reliable few minutes of believing the conversion failed when the file on the server is perfectly correct.

Check the file directly by opening its URL in a tab, which bypasses the icon cache entirely. If the correct image appears there, the deploy worked. To force the tab to update, open the site in a private window, or add a query string to the link element for one deploy.

Nothing in this conversion crops. The drawing is rendered at its own proportions, and each icon entry is then made by centring it on a square canvas at the largest scale that fits — so a wide viewBox is padded with transparency above and below rather than stretched. The icon is never distorted, which is the right default, but a mark that is three times wider than it is tall ends up occupying a third of the square and reading as a small logo floating in a large tab.

Fix it in the SVG. Set the viewBox to a square and position the mark inside it with whatever margin looks right, remembering that icons are usually displayed edge to edge with no padding of their own. A symbol that fills about ninety per cent of the square reads well at every size, and at 16 pixels the difference between filling the frame and filling a third of it is the difference between four legible pixels of stroke and one.

Drop the whole set. Each drawing is rendered and wrapped separately and the results come back as a ZIP, which is the usual shape of this job for anyone running several sites or several products from one brand system — one mark per property, all needing the same treatment on the same afternoon.

Every file gets the same treatment and the same size set, so the batch comes back consistent. What is not consistent is how much of each square the mark fills: a drawing with a wide viewBox is centred with transparent space either side, and next to a properly squared sibling it will look a size smaller. Squaring the viewBoxes is worth doing once in the source rather than noticing it afterwards across a dozen sites.