The TIFF format

A container, not a format

TIFF — Tagged Image File Format — was created by Aldus in 1986 to give desktop scanners a single thing to write, and passed to Adobe when it acquired Aldus in 1994. The word doing the work is tagged. A TIFF is a directory of numbered tags, each pointing at a piece of data, and the specification allows a great many combinations of them.

So a TIFF can be uncompressed, or use LZW, PackBits, Deflate, CCITT Group 3 or 4 for bilevel fax images, or wrap actual JPEG data inside. It can be 1 bit per channel or 16, greyscale or RGB or CMYK, one page or four hundred. It can even be written in either byte order — the two magic-number variants are still known as Intel and Motorola. Knowing that a file is a TIFF tells you remarkably little about whether a given program can open it, which is why “does it support TIFF?” has never been a yes-or-no question.

Why it has outlived its replacements

TIFF is a print and archive format, and both of those fields value different things from the web. Sixteen bits per channel survives the aggressive curves and levels adjustments that make a scan usable. CMYK and spot channels matter when the destination is ink rather than a screen. Multiple pages in one file matches how documents are actually scanned. Lossless is the default, and an embedded ICC profile keeps the colour meaningful between devices.

The result is that TIFF is the master format in places nobody sees: prepress and print production, museum and national-archive digitisation, GeoTIFF for satellite imagery and maps, microscopy, and the output tray of essentially every document scanner. Formats have been proposed to replace it repeatedly. Each of them solved a piece of the problem, and TIFF kept the whole of it.

Its other legacy is invisible: EXIF, the metadata block inside almost every JPEG your camera has ever produced, is structurally a small TIFF directory. The format outlived its rivals partly by being embedded in one of them.

What happens when you convert one here

No browser decodes TIFF, so this tool does it in JavaScript, with a decoder called utif that is downloaded only when you actually open a TIFF. That decode drives the interface as well as the output, which is why a TIFF gets a real thumbnail and a real crop preview rather than a placeholder — what you see is what converts.

Three consequences are worth stating plainly.

• Orientation is applied deliberately. utif reads the Orientation tag and leaves the pixels as stored, so the rotation is applied here, before resizing or cropping, rather than left to whatever opens the file next.
• Only page one converts. Everything after the first image in the file is discarded.
• The pipeline is 8-bit sRGB. A 16-bit scan is reduced on the way in, and the output is sRGB regardless of what the source was tagged with. Any EXIF the file carried, including GPS coordinates, is dropped.

Why there is no TIFF encoder here

Writing a TIFF from this pipeline would mean writing a large file that had none of the properties people keep TIFFs for. It would be 8-bit, sRGB, single-page, no layers, no CMYK — the same information the JPEG would have carried, in an archive format’s clothing, at several times the size. No browser can encode one either, so it would mean shipping another WebAssembly module to produce a worse outcome.

The formats written here are the five that make sense as an output for a screen: JPEG, PNG, WebP, AVIF and GIF. TIFF is an input, and an important one.

What to convert it to

JPG for sending a scan to somebody, or for a proof. Use a high quality setting — a TIFF is usually something a person cared enough about to scan properly.

PNG when the pixels must not move. Lossless, exact, and large — though only 8 bits per channel, so it is not a substitute for the original.

WebP or AVIF when the destination is a web page. Both are far smaller than a JPEG of comparable quality, and both display everywhere current.

And keep the TIFF. It is the master file, and nothing produced from it can be turned back into one.