Skip to main content

GIF to TIFF converter

Convert GIF images to TIFF format

No watermarkFree & unlimited
All processing happens in your browser. No data is sent to any server.

TIFF is what publishing, scanning and document systems ask for, and GIF is what those systems almost universally refuse. The bridge built here is deliberately simple: the frame your browser renders is written as a baseline little-endian TIFF with no compression, three eight-bit samples per pixel and a single strip. Pixel values carry over exactly, so nothing is degraded, but two structural things disappear. Animation is reduced to the opening frame, and the alpha channel is discarded, leaving transparent regions solid black.

Key facts about GIF to TIFF converter

Key facts about GIF to TIFF converter
TIFF flavour producedBaseline TIFF: the II little-endian marker, version 42, a ten-tag directory, PhotometricInterpretation 2 for RGB and chunky planar configuration.
CompressionWritten as 1, meaning stored. The GIF LZW compression is undone rather than translated, and no Deflate or JPEG-in-TIFF option exists here.
Size changeLarge and one-directional. A 500x500 GIF of 40 KB becomes 750,134 bytes, since each pixel takes three raw bytes plus a 134-byte header.
Exact size formula134 bytes of structure plus width times height times three. A 1920x1080 frame is always 6,220,934 bytes.
Transparency lost to blackThree samples per pixel with no ExtraSamples tag, and a transparent canvas pixel reads back as zero, so see-through areas become solid black.
Frames and pagesOne of each. The GIF is drawn once and the directory chain terminates after the first entry, so the TIFF is single-frame and single-page.
Colour fidelityExact. No lossy codec touches the pixels, so all 256 colours of the GIF frame are reproduced bit for bit.
Opens the resultPhotoshop, GIMP, Affinity, ImageMagick, macOS Preview, Windows Photos, and the OCR and prepress tools that reject GIF at intake.

What happens to your file

The TIFF is constructed locally from start to finish. Your GIF is exposed through an object URL, decoded by the browser's built-in GIF reader, and drawn onto a canvas owned by this tab. The page reads that canvas back with getImageData, drops the alpha byte from every pixel into a new RGB array, and writes the header, the ten directory entries and the pixel strip into an ArrayBuffer with a DataView. No network request occurs.

About this tool

  1. 1

    Add the GIF files

    Drop up to twenty .gif files on the target area, each as large as 500 MB, or click to browse.

  2. 2

    Flatten transparency first

    Anything shown as checkerboard will be black in the TIFF, so composite it over a background beforehand if that matters.

  3. 3

    Leave the size alone for archives

    Resize presets are the only control over output size, but resampling costs detail a document workflow may need.

  4. 4

    Convert and save

    Press Convert. Writing is quick with no encoder to run, and multiple files return as converted-tiff-files.zip.

Specs & compatibility
Input and outputTakes .gif only (image/gif) and returns .tiff with the image/tiff type; any other extension is refused before decoding.
Conversion pathGIF to TIFF runs in three steps: an <img> element decodes the GIF and only its first frame reaches the canvas; the pixels land on a 2D canvas in this tab; then getImageData feeds a baseline IFD writer that assembles the file in page memory.
Browser supportThe GIF side decodes in every browser ever shipped, while writing the TIFF needs nothing from the browser, the directory being written in the page.
Controls for this pairNo quality slider, TIFF not being a lossy target here, so the max-dimension presets from 3840 down to 200 px are the only way to hold the TIFF down in size against the GIF.
Batch, caps and namingTwenty GIF files per run at 500 MB each; one result downloads as a single TIFF, several as converted-tiff-files.zip, zipped by JSZip 3.10 in page memory.
Device ceilingThe canvas caps it: past roughly 16,384 px a side Chromium refuses the bitmap and iPhone Safari gives up sooner, so an oversized GIF fails before any TIFF bytes exist.
  • Archive the TIFFs inside a zip if you are sending them, since uncompressed pixel data compresses extremely well externally.
  • A GIF frame has at most 256 colours, so if the recipient tolerates PNG you get an identical picture for a fraction of the bytes.
  • When the TIFF feeds OCR, avoid resizing; the recogniser works better on the pixels as rendered.
  • If the receiving software rejects the file, it almost always wants a compressed or multi-page TIFF.
  • Baseline uncompressed RGB TIFF output
  • Bit-exact pixel pass-through from the frame
  • Ten-tag little-endian IFD built in the page
  • Twenty GIFs per run, zipped locally
  • Submitting artwork to a print shop or prepress intake that lists TIFF as the accepted format.
  • Feeding a document capture or OCR pipeline that refuses GIF files outright.
  • Archiving a decoded GIF frame where professional imaging software opens it without plugins.
You have removed compression entirely. The GIF stored one palette index per pixel and squeezed those with LZW, which is efficient on flat art. The TIFF stores three raw bytes per pixel with compression set to stored, so a 500 by 500 frame is 750,134 bytes whatever it contains. That is the format behaving as specified.
No. The writer always sets Compression to 1 and terminates the directory chain after the first entry, so every output is single-page and uncompressed. Converting twenty GIFs gives twenty separate files in a ZIP rather than one twenty-page document. Combining them requires ImageMagick or a scanning application.
It becomes black. The TIFF is written with three samples per pixel and no ExtraSamples tag declaring alpha, so the alpha byte is skipped, and a fully transparent canvas pixel reads back as zero in every channel. Composite the GIF over your intended background in an editor before converting.
Not at all. No lossy codec is involved on either side, so the exact RGB values the browser decoded are written into the TIFF strip. The losses are structural rather than visual: animation, alpha and palette organisation are gone, but the picture itself is unchanged.
No, and that is worth being explicit about, because multi-page TIFF is a real feature of the format. The conversion draws the GIF once and the writer emits a single image file directory. Going from a twenty-frame animation to a twenty-page TIFF needs a tool that parses GIF frame blocks.

Related tools

View all

Need the opposite? Try TIFF to GIF

Updated

We use anonymous analytics to improve ToolChamp. No personal data is stored or sold. Privacy Policy