Convert ICO to PNG

This is the thing most converters do not tell you. An ICO is not an image; it is a small directory with several images inside it, each at a different size, so that Windows can show a crisp 16-pixel version in a crowded taskbar and a crisp 256-pixel version on the desktop without scaling either. A well-made application icon commonly holds four to six entries. A PNG has room for one picture and no directory at all.

So the conversion is not a re-encoding, it is a selection followed by a re-encoding, and the interesting question is which entry gets selected. Everything else on this page follows from that.

The decoding is done by your browser rather than by a library shipped with this page, and every browser icon decoder returns the biggest image in the directory. That was measured rather than assumed: an icon file built with 16, 32, 48 and 256 pixel entries, each drawn in a different colour so the result could not be mistaken, came back as a 256-pixel PNG in the colour of the 256 entry. Rewriting the directory smallest-first, largest-first and shuffled changed nothing.

The practical consequence is that you cannot choose. If the file holds a 256-pixel image, that is the one you get; the 16, 32 and 48 pixel drawings are discarded without a message, and they are frequently the ones somebody spent the most time on.

An ICO entry records its width and height in a single byte each, which stops at 255, and the format reserves the value 0 to mean 256. That is the whole ceiling: no icon file anywhere holds an image wider than 256 pixels, so no PNG produced from one can be larger either.

This matters when somebody has asked you for a logo. An icon file is not a source asset, and a 256-pixel PNG placed on a slide at full width or printed at any size will look soft. If the PNG is destined for anything larger than a thumbnail, go and find the original artwork rather than converting the icon; the icon was made from it, not the other way round.

Both formats carry a proper eight-bit alpha channel, so a rounded icon, a cut-out mark or a soft drop shadow arrives in the PNG exactly as it was drawn. There is no background colour to choose and no white box to crop off afterwards. On a test icon the corner pixel of the output reads 0,0,0,0 — fully transparent, not black at zero opacity.

That is the reason PNG is the right target for this and JPG is not. If the icon is going anywhere it might sit on a coloured background — a dark documentation theme, a slide, an app store grid — the alpha channel is the entire point of doing the conversion at all.

Both ends are lossless. The icon is decoded to raw pixels and those exact values are written into the PNG, so there is no quality setting to get wrong and no generation loss if you convert the same file twice. What changes is the packaging, not the picture.

The PNG is then run through oxipng, which typically removes a large fraction of what the plain encoder writes without touching a single pixel. On the 8,471-byte test icon the resulting 256-pixel PNG was 1,737 bytes — smaller than the icon it came from, because the icon was carrying four copies of the same drawing and the PNG carries one.

If the small entry is what you actually want, this page cannot give it to you and neither can any converter that goes through a browser decoder. The small sizes in a good icon are not scaled-down copies; they are redrawn, with strokes snapped to whole pixels and detail removed so the mark stays legible at that size. Shrinking the 256-pixel PNG produces something visibly worse.

The tool for the job is an icon editor. GIMP opens an ICO and presents every entry as a separate layer, which you can export one at a time, and it costs nothing. IcoFX does the same on Windows with a friendlier interface.

Favicons pulled off the web are usually much smaller than the ceiling suggests. A file written before high-density screens mattered often holds only a 16-pixel image, sometimes a 16 and a 32; the 256-pixel entry became common only once Windows and browsers started using it for larger tiles. So a favicon.ico from an older site can produce a 16-pixel PNG, and that is the honest maximum of what was in the file.

The result will look correct and be almost unusable for anything but a favicon. It is not a fault of the conversion — the picture at any greater size was never stored. Treat it as evidence that the site never published a large version, and go looking elsewhere for the mark.

Modern favicon markup accepts PNG directly, and most sites now declare a 32-pixel PNG, a 180-pixel apple-touch-icon and an SVG alongside the traditional icon file at the root. If you converted an ICO to PNG in order to modernise a site, the PNG you get here is the right input for those declarations provided the source held a large enough entry.

For a native application icon the platform will ask for exact pixel dimensions — and a 256-pixel PNG cannot honestly fill a 512 or 1024 pixel slot. Where the platform wants those, the icon file is the wrong starting point and the vector or the full-resolution original is the right one.

Drop the whole set. Each icon is decoded and written out separately and the results come back as a ZIP, which is the usual shape of this job: somebody inherits a directory of application icons and needs every one of them as a picture for a documentation page or an asset inventory.

Because the work happens in your browser there is no queue and no per-file upload, and the tenth file is handled exactly like the first. Files that hold only a small entry will produce small PNGs, so check the dimensions in the ZIP rather than assuming the set is uniform — mixed icon sets almost never are.