Image to ICO — Free, Fast & Private
Asking to turn an image into an .ico sounds like the same kind of job as turning a JPEG into a PNG, and it quietly is not. Those are both single pictures in different wrappers. An icon file is a small bundle: a short index at the front, then several complete pictures behind it, each one the same artwork rendered at a different square resolution. So the real question this tool answers is not “which codec” but “which family of sizes” — you hand over one image and get back a set of renderings that travel together as a single downloadable file.
All of that assembly happens on your own machine. The image is decoded, resized at each resolution, re-encoded, and packed into the container by JavaScript in this tab, and the finished file is produced by the page rather than fetched from anywhere. That matters more than the usual privacy boilerplate suggests, because the artwork people convert to icons is disproportionately unreleased branding — a mark that has not shipped yet, a client asset under agreement, a side project nobody has seen. It stays on your disk.
What is actually inside an .ico file
Open one in a hex editor and the structure is refreshingly plain. Six bytes at the top declare that this is an icon and count how many pictures follow. Then comes one sixteen-byte record per picture, and each record is a tiny address card: how wide the image is, how tall, how many bytes it occupies, and how far into the file it starts. After all the records, the picture data sits back to back. Nothing is interleaved and nothing is compressed at the container level — the wrapper is pure bookkeeping, and the pictures inside carry their own compression.
Because every record carries an offset and a length, a reader never has to parse the whole file. It skims the index, decides which entry it wants, seeks straight to that offset, and reads exactly that many bytes. This is why a four-resolution icon costs a browser almost nothing: it reads the header, takes the entry that matches its display, and ignores the rest of the file entirely. The pictures MiniPx writes into those slots are complete PNG files, stored byte for byte, and the encoder verifies each one begins with the PNG signature before it is packed — a container whose index promises one thing while the payload is another fails silently and mysteriously days later, so it is checked at write time instead.
Why two programs read the same file and show different pixels
Nothing in the format tells a reader which entry to use. Each consumer decides for itself, and their reasoning differs enough to be surprising. A browser drawing your tab has a slot roughly sixteen CSS pixels wide, so on an ordinary display it reaches for the 16px entry — but on a Retina or 4K screen that same slot is thirty-two device pixels, and the browser takes the 32px entry instead. The favicon looks identical to the user and came from two different pictures.
Windows is fussier still, because the shell asks by view context rather than by pixel count alone. Explorer's small-icons list wants 16, its medium view wants 32, large wants 48, and extra-large jumps to 256. Layer display scaling on top and the numbers stop being round: at 150% scaling the taskbar effectively wants a 24px icon, which no ICO carries as a standard entry, so the shell grabs the nearest larger picture and shrinks it. That last behaviour explains most of the blurry icons people blame on their artwork. When a reader cannot find the size it wants, it does not give up — it rescales the closest thing, and a 48px picture squeezed into a 24px box loses the crispness the 32px entry would have kept.
Which resolutions belong in the bundle
Think of the size list as a menu you are printing for readers you will never meet, and the cost of an extra dish is only kilobytes. Sixteen and thirty-two are non-negotiable: between them they cover standard and high-density browser tabs, which is where most icons spend their lives. Forty-eight earns its place the moment the file ever touches a desktop — shortcuts, Explorer's medium and large views, and the alt-tab switcher all live in that neighbourhood. Two hundred and fifty-six exists for one reason, the extra-large Explorer view and pinned-site tiles on Windows, and it is the only entry heavy enough to think about.
Where the file will live decides the trade. A website favicon is requested by every visitor on every cold load, so the classic 16/32/48 trio is the sensible default and the 256 entry is optional weight you are asking strangers to download. An icon destined for a Windows application, a shortcut, or a folder should carry all four, because the shell will otherwise improvise, and improvised rescaling is exactly the softness you are trying to avoid. Each resolution here is rendered independently from your original rather than chained off the previous one, so the small entries are as sharp as the source allows.
What your source image needs to survive the shrink
PNG, JPEG, and WebP are all accepted. PNG and WebP bring an alpha channel with them and it comes through intact, which is what lets an icon sit on a dark tab strip or a photographic wallpaper without a rectangle of background around it. A JPEG has no transparency to carry, so whatever colour fills its corners will fill the corners of the icon too — if that is a white box around a logo, the honest fix is to remove the background before converting.
Shape is handled without surprises: a non-square source is centred on a transparent square rather than cropped or stretched, so a wide wordmark arrives complete with empty space above and below. Detail is the part no converter can fix for you. At 16 pixels square there are 256 pixels in total, which is fewer than the characters in this sentence, and anything with hairline strokes, gradients, or readable text turns to mush at that scale. Photographs make particularly poor icons for the same reason. If your mark is intricate, convert a simplified version — one glyph, one shape, one initial — and keep the full lockup for places with room to show it.
Where the finished icon goes
For a website, the file belongs at the root of your domain as favicon.ico, because browsers request that exact path out of habit even when no markup mentions it. On Windows, a shortcut takes one through Properties and Change Icon, a folder takes one through its desktop.ini, and a compiled application takes one as an icon resource at build time. Each of those surfaces reads the container the same way and simply chooses a different entry.
If you need more than the .ico — the Apple home-screen icon, the manifest pictures Android reads on install, and the markup to declare them all — the favicon generator produces that whole set in one pass around the same engine. And if the source image you are starting from is an unoptimised export, running it through the PNG compressor is worthwhile for the copy you keep, even though the icon entries are re-encoded here anyway.