How ICO to PNG Extraction Works in Your Browser
An ICO file is a small binary container with a strict layout: a 6-byte ICONDIR header — reserved field, a type field that must equal 1, and the count of images — followed by a 16-byte directory entry for each embedded image. Every entry declares, in little-endian order, the image's width and height (where the value 0 means 256), palette depth, color planes, bits per pixel, the byte length of the payload, and its offset from the start of the file. The converter reads this structure directly with a DataView, validating the magic fields, then scans every entry to find the one with the greatest width-times-height area.
Once the largest entry is identified, its byte range is sliced from the file and wrapped in a Blob. For icons produced on Windows Vista and later, that payload is itself a PNG, which the browser decodes natively through an HTMLImageElement — the same pipeline used for any PNG on the web. The decoded bitmap is drawn onto a canvas at its natural dimensions with drawImage() and — importantly — no background is painted first, so the icon's alpha channel survives intact. The final canvas.toBlob(..., 'image/png') re-encodes the pixels losslessly into a standalone PNG.
The one structural caveat is older icons: before Vista, Windows commonly embedded classic BMP-style DIB payloads rather than PNGs. Browsers cannot feed a DIB to an image decoder, so such entries fail at the decode step and the tool reports an error rather than guessing. This is an honest format boundary, and it is also a privacy boundary — the tool never reaches for a server-side decoder to handle what the browser cannot, keeping the guarantee that your icon file is processed by nothing but your own device.