Convert ICO to TIFF

That is the situation this page exists for, and the first useful thing to say is that the two requests are in tension. TIFF is asked for by workflows that care about resolution: prepress, scanning, document archives, anything that will be looked at closely or reproduced on paper. An icon is the smallest deliberately-made image in software, drawn to be legible at 16 pixels.

The conversion works and produces a valid file. Whether that file is fit for the job is a separate question with a numerical answer, which the next section gives. Ask it before the file goes any further, because it is much cheaper to find the real artwork now than after a proof comes back.

An ICO entry stores its dimensions in a single byte with zero standing in for 256, so 256 pixels is the absolute maximum any icon file can contain. Print is normally specified at 300 dots per inch, and 256 divided by 300 is 0.85 inches — 21.7 millimetres. At 600 dpi, which fine work uses, it is 10.8 mm.

So the honest maximum for a printed icon is about the size of a postage stamp, and many icon files hold nothing above 32 or 48 pixels, which comes to 2.7 or 4.1 mm. Placed larger than that, the softness is not subtle. If the mark has to appear at 40 mm on a cover, the icon cannot supply it and no conversion will change that.

TIFF is less a format than a filing system for images, and its readers agree on less than the name suggests. LZW is patent-free and universally supported; Deflate is not universally supported; JPEG-in-TIFF is a different image inside a TIFF wrapper and defeats the reason most people ask for one. The baseline uncompressed form is the single variant that every reader accepts.

Somebody converting to TIFF is almost always feeding something particular — a press, a scanner’s software, an ingest folder — and the cost of a file that one link in that chain refuses is far higher than the cost of some disk space. That is the trade this converter makes on your behalf, and it is stated here rather than hidden.

The arithmetic is worth doing because it tells you what is in the file. A 256-pixel square at four samples per pixel is 262,144 bytes; the measured result was 263,144, leaving a kilobyte of directory and tags. Four samples means red, green, blue and alpha, so the icon’s transparency is written rather than discarded.

Written is not the same as honoured. TIFF readers vary in how they treat a fourth sample: some composite it against white, some present it as a selectable channel, and some ignore it and show the raw colour underneath, which for a cut-out icon looks black. Open the result in the application that will actually consume it before you decide the transparency worked.

The largest. Your browser decodes the container and returns its biggest image, which was verified by constructing an icon holding 16, 32, 48 and 256 pixel drawings in four separate colours and converting it three times with the directory ordered differently — the 256-pixel drawing came out each time.

That is the best available outcome for this target, since resolution is what a TIFF workflow wants. It also means the result is as good as the icon gets: there is no setting that enlarges, and the maximum-width control here only ever shrinks.

There is an irony in this pair. Both formats are containers built to hold several images: an ICO carries the same mark at several sizes, and a TIFF can carry several pages, which is why scanners produce one file for a twelve-page fax. In principle the whole icon set could travel across intact.

It does not. The decoder hands back one picture and the writer emits one page, so a four-entry icon becomes a single-page TIFF and the other three drawings are gone. If preserving the set matters — for an archive record, say — keep the original ICO alongside the TIFF rather than treating the TIFF as a replacement.

A TIFF begins with two characters that say which way round its numbers are stored: II for little-endian, MM for big-endian, followed by the number 42. The files written here begin MM. Both are legal and every reader handles both, but it is the sort of thing that surprises somebody comparing two files byte by byte and concluding one of them is corrupt.

The rest of the header is a pointer to an image file directory, which is where the width, height, samples per pixel and strip offsets live. That indirection is what lets TIFF hold several images, and it is also why a TIFF cannot be identified by its first four bytes as confidently as a PNG can.

If this file is going to be printed at any meaningful size, the right move is to go back and ask for the artwork the icon was made from. Icons are derived assets; somewhere there is an SVG, an AI file or a large PNG that the 256-pixel entry was rendered down from, and it will produce a TIFF at whatever resolution the press wants.

Where the icon genuinely is all that survives — an old product, a defunct vendor, a screenshot taken from a running system — the conversion here gives you the best that exists, and the size limit should be stated to whoever specified the layout rather than discovered at proof stage.

Drop the whole set and each file is decoded and written independently, with everything returned as a ZIP. Expect the ZIP to be large in a way the source folder was not: a few dozen icons of eight kilobytes each become a few dozen TIFFs of a quarter megabyte each, and the ZIP compresses uncompressed image data only moderately well.

For an archival record that is usually acceptable and sometimes the point, since an uncompressed file has no decoder to become obsolete. For a working set it is worth asking whether PNG would satisfy the same requirement at a hundredth of the size.