What's Actually Inside a .ico File (And Why One Icon Is Never Just One Image)

Open almost any other image format and you get exactly one picture. Open a .ico file and you can get several, quietly bundled together, with the operating system picking which one to actually show you depending on where it's needed. Most people never open that container to see what's inside. Here's what's actually in there, layer by layer.

Layer one: the header, three numbers deciding everything that follows

Every ICO file opens with a small header block, six bytes, that establishes exactly three things: a reserved field that's always zero, a type flag confirming this is an icon file rather than a cursor file (ICO and the less common .cur format share the same underlying container), and a count of how many images are bundled inside. That count is the number that matters, it's the difference between a file holding one lonely 32×32 image and one holding a proper set built for every context it might be needed in.

Layer two: the directory, one entry per size, before any actual image data

Right after the header comes a directory, one entry per bundled image, and each entry is metadata only, no pixels yet. Every entry records the width and height of that particular image, its color depth, and critically, an offset telling the file reader exactly where in the file that image's actual data begins. This is what makes an ICO file efficient to read: an application asking for "whatever fits a 16-pixel slot" can scan this short directory, find the matching entry, and jump straight to that image's data without touching any of the other sizes bundled alongside it.

Layer three: the images themselves, re-rendered, not just resized

Here's the part that surprises people who assume "multi-size icon" means one image copy-pasted at different sizes. It doesn't work that way, and it can't. Each size inside a well-built ICO file is typically rendered independently, not stretched from a single master, because a 256×256 icon and a 16×16 icon are trying to communicate the same design under wildly different amounts of available detail. A 16×16 rendering of a detailed logo often needs simplified linework, fewer visible elements, sometimes an entirely adjusted composition, to remain legible at that size, the same artwork blindly shrunk down from a large source frequently turns to an illegible smear of a few dark pixels instead.

Modern ICO files typically store each of these embedded images as PNG data internally, a change from the older uncompressed bitmap approach used before Windows Vista, which is part of why a modern multi-size ICO file isn't dramatically larger than you'd expect for holding several images at once.

What happens when you actually convert into ICO

We ran a real JPG, 67.65 KB, through our converter set to output ICO, and the result came back at 116.08 KB, a 72% increase. That's expected once you understand what's happening in layers two and three above: the source photo is being rendered out at multiple standard icon dimensions, 16×16, 32×32, and 48×48 in our tool's case, each one drawn independently with its own scaling pass, then packaged together with the directory structure holding them all. You're not getting one compressed file, you're getting several images bundled into one container, so a size increase over the single source photo is the normal outcome, not a sign anything went wrong.

Where ICO actually still matters in 2026, and where it doesn't anymore

The role ICO plays has shifted. For years it was the default answer to "how do I make a favicon," full stop. That's no longer accurate. Current favicon guidance treats a scalable SVG icon as the primary format for modern desktop browsers, Chrome, Firefox, Edge, and Safari from version 15.4 onward all render SVG favicons directly, covering the large majority of browser traffic in 2026. ICO has been repositioned as the fallback and compatibility layer sitting behind that SVG, not the primary format anymore, still necessary because a small number of older or less common browser configurations don't render SVG favicons, and because Windows specifically still expects an ICO file for taskbar pins regardless of what a site's SVG favicon looks like. Practically, that means a well-built modern site ships an SVG favicon as the main icon and keeps a multi-size ICO alongside it as insurance, rather than treating the ICO as the whole solution the way sites did a decade ago.

The one mistake that ruins icon quality before conversion even starts

Nearly every quality complaint about a converted ICO traces back to the same root cause: starting from a source image that's already too small, and then having every size inside the ICO built by upscaling that undersized source rather than downscaling from something larger. A 64×64 logo asked to produce a 48×48 icon is working with barely any room to spare and close to none for anything larger. A 512×512 or larger square source, ideally with the design's important details still legible if you mentally shrink it down to the size of a thumbnail, gives a converter's scaling passes actual detail to work with at every size the resulting ICO needs to hold. The fix isn't a setting on the conversion side at all, it's making sure the file going in is large enough that scaling down, the direction every one of these tools is actually built for, is the only direction being asked of it. Generate crisp multi-size icon packages in your browser with our converter.