Convert ICO to GIF

This is the first thing to say and most pages about this conversion never say it. GIF does support transparency, but only in one narrow form: a single palette entry may be nominated as invisible. The encoder behind this page does not nominate one. It builds a palette from the image, writes it as a list of red-green-blue triples, and the alpha information is gone by the time the file is assembled.

So the cut-out is filled in before it reaches the encoder. The see-through pixels are painted with the background colour set above the drop zone, white unless you change it, and then the palette is computed from the result. A rounded logo that floated in the ICO arrives in the GIF sitting on a solid square. Set that square to the colour of the page it is going on and nobody can tell; leave it wrong and the square is the first thing anyone sees.

The colour is a control on this page, above the drop zone, and it is worth a moment rather than a shrug. It was not always there: until August 2026 the flattening happened silently inside the quantiser and every cut-out came back on black, measured at 0,0,0,255 in the corner of a test file. The fill is now applied before the palette is built, so the colour you choose is one of the 256 entries and the antialiased edges blend into it cleanly instead of into black.

If the destination is an email signature, that colour is almost always white, because mail clients render on white and a dark-mode client will invert the surrounding page and not your image. If it is an intranet with a coloured header, match the header. If you want something a flat fill cannot give you — a gradient behind the mark, or artwork that has to overlap the edges — do the compositing in GIMP or whatever produced the icon and convert the flattened result instead.

GIF is thirty-nine years old and it is the most universally readable image format that has ever existed. Every mail client, every forum engine, every industrial control panel and every piece of enterprise software written before about 2005 reads one. That is why specifications still name it: not because anyone prefers it, but because the person writing the specification wanted an answer that could not fail.

The corollary is that the destination is probably old enough to have other constraints too — a maximum pixel size, a maximum byte count, a fixed aspect ratio. Read the rest of that specification before converting, because it is unlikely that the format was the only thing it pinned down.

GIF stores an index per pixel into a table of at most 256 colours, which is the reason photographs turn to visible bands inside one. An icon is a different animal: flat fills, a handful of brand colours, and antialiasing along the edges that adds intermediate shades. Even counting those, most icons land well under the ceiling and quantise without a visible change.

Where it does bite is a mark with a real gradient — a sphere, a metallic bevel, a soft glow. Those generate hundreds of distinct values across a small area, and the palette reduction shows as stepping. If your icon has one, look at the result at full size before sending it.

People associate GIF with movement, so it is worth being explicit: there is nothing to animate here. An ICO holds the same picture drawn at several sizes for different display contexts. It has no concept of time, no frame delays and no loop count, and the encoder here writes exactly one frame.

If what you need is a moving version of a logo, this is not the conversion — that starts from a video or from an animated source and goes through a different tool entirely. Nothing you do to an icon file will produce one.

The largest. Your browser decodes the container and returns its biggest entry, which was checked by building a file with 16, 32, 48 and 256 pixel images in four separate colours and converting it three times with the directory ordered differently: the result was the 256-pixel drawing every time.

And 256 is the hard ceiling, because an icon entry stores its dimensions in one byte with 0 standing in for 256. So a GIF made this way is never larger than 256 pixels on a side, whatever the destination asks for. A specification demanding a 400-pixel GIF cannot be satisfied from an icon file without upscaling somewhere else.

Small, and often smaller than expected. GIF compresses runs of identical palette indices, and flat icon artwork is nothing but runs. On the test file — 8,471 bytes of icon holding four entries — the 256-pixel GIF came out at 1,894 bytes.

That is competitive with the PNG of the same image, which was 1,737 bytes. The gap is small enough that byte count is never the reason to pick one over the other here. Transparency is the reason, and on that measure the PNG wins outright.

Worth one attempt before committing to a flattened background. Many systems that name GIF in their documentation accept PNG in their code, because the validation was written later than the help text and covers everything the underlying library reads. If it goes through, you keep the transparency and lose nothing.

Where GIF is genuinely required — a mail template rendered by something ancient, a device that displays images from a fixed decoder — take the GIF and set the background colour to match its destination. The result is then correct rather than merely accepted.

Drop the folder. Every file is decoded, quantised and encoded independently and comes back in a ZIP. The palette is built per image rather than shared across the set, so two icons using the same brand colour can end up with that colour at slightly different indices — invisible in use, but it means the files are not interchangeable at the byte level.

The background colour, on the other hand, is one setting for the whole drop, so every icon in the set is flattened onto the same fill. That is what you want for a set going into one template — and it is also why converting half a set now and half of it later is how the two halves end up on different colours.