Convert PNG to ICO

An ICO is not one picture, and that is the whole story

Nearly every image format holds a single picture. ICO holds a small archive of them. Inside one file sits a directory listing several complete images, each drawn at its own edge length, and the software displaying the icon reaches in and takes whichever one suits the space it has. Windows does this constantly and without asking: sixteen pixels in the details column of File Explorer, thirty-two on the desktop, forty-eight in the large icons view, two hundred and fifty-six in the preview pane and the application switcher.

Hand it a file containing only the big one and it will still show you something. It will take the 256, squeeze it into a sixteen pixel square with a general-purpose filter, and the result is the smeared little blob you have seen on badly made sites for twenty years. Nothing is broken; the operating system simply had nothing better to work from. That is the single failure this page exists to prevent, and it is why the size checkboxes sit above the button instead of behind an advanced panel.

How the PNG to ICO conversion gets each size, and a piece of folklore

Reducing a 512 pixel mark to sixteen pixels discards more than 99.9 percent of what you started with, and how the survivors get chosen is the difference between a legible icon and a smudge. Each size here is reached by halving repeatedly — 512 to 256 to 128 and onward — with one short final reduction at the end that is never steeper than a factor of two.

Every guide on this subject will tell you that the alternative, asking the browser to do the whole reduction in a single operation, produces mush. That advice was worth checking before repeating it, so it got checked. Against a true area average worked out in plain arithmetic, the two approaches came back essentially tied: an average per-channel error of 0.30 versus 0.30 in Chrome at sixteen pixels, and 10.68 versus 10.66 in Safari. At twenty-four and forty-eight pixels the single operation was fractionally ahead. Both engines already filter correctly at steep reduction ratios, and the folklore is simply out of date.

The measurement did surface something more useful, though. The two engines are nowhere near each other. Given identical source material and identical instructions, Safari's output sat more than thirty times further from the ideal average than Chrome's did. No converter can repair that, this one included, because the filtering happens inside the browser rather than in anybody's code — and it is a reason to glance at your icon in more than one browser before shipping it. The one place halving held a consistent edge was hairlines: a single pixel rule near the border returned at alpha 15 instead of 11 in Safari, fading slightly less. Small, real, and free, which is why the chain stays and why this page describes it accurately instead of selling it.

Bitmap entries and PNG entries

Each entry in the archive can be stored two ways. The original design carries a raw device independent bitmap, uncompressed, with a one bit transparency mask stacked underneath the color data. Since Windows Vista an entry may instead contain a complete PNG stream, which every current reader understands.

Which to use is a genuine trade rather than a matter of taste, so both totals are measured on your own image and displayed together. At small edge lengths an uncompressed entry costs about a kilobyte and buys compatibility with everything back to Windows XP. At 256 the arithmetic changes completely: uncompressed, that one entry alone weighs 270,376 bytes, more than a quarter of a megabyte for a site icon, so it is always written as PNG regardless of which mode you choose. Switching between the two after a build repacks instantly, because both forms of every entry were produced while the picture was being scaled.

One detail of the bitmap header deserves naming, because getting it wrong is the classic bug behind icon files that render as garbage or refuse to load. The height field must state twice the real height. It describes the color image and the mask stacked together, not the picture, and a writer that puts the honest number there produces a file readers will misparse from the first entry onward.

Transparency has to survive, or the icon is useless

A site icon appears on backgrounds you do not control. Browser tab strips are light in one theme and dark in another, and a favicon that lost its alpha channel arrives with a white rectangle behind it that looks like a rendering fault. Every entry here is written with a full eight bit alpha channel, and the old one bit mask is filled in alongside it for readers that still consult it.

The claim is also checked rather than asserted. Any picture drawn through a canvas comes back as four channel data whether or not it had transparency to begin with, so the presence of an alpha channel proves nothing at all about the image. Only reading actual pixel values can settle it, which is what happens on arrival and again on the finished entries — and if your source turns out to be fully opaque, the tool says so before you build rather than leaving you to discover it on a dark background later.

Getting the file onto a site

Put it at the root of your domain under the name favicon.ico. Browsers request that exact path unprompted, with no markup involved, which is the reason a format from 1985 has outlasted several intended replacements. Declaring it explicitly with a<link rel="icon"> tag is optional and still worth doing, because the tag can list the sizes the file genuinely contains. The snippet produced after a build is written from the boxes you ticked rather than copied from a template, so it never advertises a size that is not in there.

What this tool deliberately does not do

It does not make .icns files. That is Apple's icon container, a different structure with different rules, and pretending an ICO will serve is how people end up with application bundles showing a blank page. It also does not produce an SVG favicon, which is a separate and genuinely good idea for modern browsers: a vector icon scales to any density and can respond to dark mode, but it cannot replace the ICO, because the automatic root request only ever asks for the one filename.

Nor is there any server involved. Decoding your picture, scaling it and assembling the archive are things your browser already knows how to do, so the work happens where the file already is and nothing is transmitted anywhere. If you would like to confirm that rather than believe it, the network panel settles it in about thirty seconds. Should you need the same picture in ordinary formats instead of an icon,PNG to JPG and PNG to WebP are the neighboring routes, and compressing it to a target size is a different job again.