Convert GIF to TIFF

Requirements that name TIFF almost always trace back to document and photographic digitisation, where the format earns its place: 16 bits per channel, CMYK and Lab colour, embedded ICC profiles, and a tag structure that has been readable since 1986. An archive standardising on it is protecting scans of paper against the next thirty years.

A GIF that came off a website in 2003 fits none of those cases and still has to satisfy the same rule. This conversion produces a compliant file, and the sensible expectation is that it complies rather than that it benefits. Where the deposit allows PNG as an alternative for born-digital graphics, that is the better fit and a far smaller file.

The TIFF produced here is a baseline uncompressed file: every pixel is stored as four channel values, one after another, with a tag block describing the geometry. A 480 by 270 image is 518,400 bytes of pixel data whatever the picture shows, plus a small header.

TIFF does define compression schemes — LZW, Deflate, and the fax codings — and this converter uses none of them. That is a deliberate trade towards the widest possible compatibility, because the one thing every TIFF reader ever built accepts is the plain uncompressed baseline, and a file that an archive’s validator cannot parse has failed at the only job it had.

A GIF can declare one palette entry transparent, and almost every other still conversion on this site has to do something about that — fill it with white, ask you for a colour, or drop it silently. TIFF has an alpha channel and this path writes it through unchanged.

The consequence for an archive is that the file preserves the graphic as it was authored, including the fact that it was designed to sit on an unknown background. If the deposit specification demands a flat opaque image instead, that is a request to composite the graphic onto a defined background first — which the JPEG or BMP route does explicitly, with a colour you choose.

TIFF is a container, and among its capabilities are multiple images in a single file, layers, and a tag block that other applications extend with their own data. Multi-page TIFF is how a scanned twenty-page report travels as one object.

This conversion writes a single image. An animated GIF is decoded to its first frame and that frame is what the file contains, so the sequence does not become a multi-page TIFF. If the frames matter as a set, extracting them individually and assembling the pages in a dedicated tool is the route, and it is a different job from this one.

It is worth naming exactly what is being deposited. A GIF frame is an index into a palette of at most 256 colours, and that palette was chosen — usually by an application, usually with dithering — at the moment the GIF was created. Everything the original artwork had beyond those 256 values was discarded then.

The TIFF preserves the result of that decision faithfully and permanently, which is genuinely what an archive wants: the object as it circulated, not a guess at what it might have been. What it cannot do is undo the quantisation, and no format, setting or later processing step will. A dithered gradient stays a dithered gradient at 16 bits per channel exactly as it was at eight.

Print workflows think in physical size: a figure is 90 millimetres across at 300 dots per inch. A GIF records nothing of the kind. It stores a pixel grid and no statement about how large that grid is meant to be on paper.

So the resolution question cannot be answered by the conversion and has to be answered in the layout. A 480-pixel-wide graphic placed at 300 dpi is 40 millimetres across, and enlarging it beyond that in the page layout does not add detail — it enlarges the pixels. If a print specification demands a minimum effective resolution, check the pixel dimensions against the intended physical size before converting, not after.

TIFF’s browser support is recorded as none. No browser ever implemented it, so the file cannot be checked by dragging it into a tab, cannot be embedded on a page, and cannot be previewed in most web-based review tools.

That is a feature in the context it is used for — an archival master is not meant to be the delivery copy — but it does mean keeping a viewable version alongside it. The usual arrangement is the TIFF in the repository and a PNG or JPEG as the access copy, generated from the same source rather than from the TIFF.

If the specification permits any lossless format and merely lists TIFF first, PNG is the better answer for a GIF. It is lossless in exactly the same sense, it keeps the alpha channel, every browser and viewer opens it, and it will be a fraction of the size because it actually compresses.

The case for going ahead is when the requirement is written as TIFF and is not negotiable, or when the file is joining a collection where every other object is a TIFF and consistency has its own value. Both are common, and neither needs the conversion to be pretending it improved anything.

Decoding and encoding both happen in the browser tab, with no server involved and no account. For material bound for an archive that is frequently a hard requirement — a chain-of-custody rule that says nothing may pass through a third party — and it is satisfied here by there being no third party in the path.

The free tier accepts files up to 100 MB, which for a GIF is an extraordinarily large one. Converting a folder of them works the same way and produces one TIFF per input, downloadable together.