Initializing... drag & drop files here
Supports: TIFF, TIF
.tif/.tiff images. Multi-page TIFFs are read frame-by-frame (each IFD becomes a GIF frame), and uploading a sequence of single-page TIFFs produces one animated GIF in alphabetical order.TIFF (Tagged Image File Format, Adobe revision 6.0 from June 1993) is the workhorse of print production, scientific imaging, and document scanning — it supports 1, 8, and 16-bit depth per channel, LZW/Deflate/JPEG/ZSTD compression, alpha channels, layers, and multiple pages stacked as IFDs inside one file. GIF89a is the opposite trade-off: a single 8-bit indexed palette (256 colors max), LZW-only compression, binary transparency, and built-in frame-timing — built for the web, not for fidelity. Converting bridges the two when you need to preview, share, or animate TIFF content where GIF playback is the lowest-friction option.
| Property | TIFF | GIF |
|---|---|---|
| Released / spec | Aldus/Adobe, rev 6.0 (1993) | CompuServe GIF89a (1989) |
| Color depth | 1, 8, or 16-bit per channel (up to 48-bit RGB) | 8-bit indexed (max 256 colors per frame) |
| Compression | None / LZW / Deflate / JPEG / ZSTD / PackBits | LZW only |
| Animation | No (multi-page IFD, but no frame timing) | Yes, native frame timing |
| Transparency | Full alpha channel (8-bit) | Binary (on/off, 1-bit) |
| Max dimensions | 4 GB per file; 2^32 pixels per side | 65,535 x 65,535 pixels |
| Typical file size | 5-50+ MB per page (uncompressed/LZW) | 50 KB - 5 MB (palette-dependent) |
| Browser support | None natively | Universal (since the 1990s) |
| Best for | Print, archival, scans, scientific data | Web animations, memes, UI loops |
| Setting | Effect | Choose when |
|---|---|---|
| 256 colors + Dither | Best fidelity, largest file | Photos, gradients, scanned color art |
| 128 colors + Dither | ~30% smaller, mild banding | General-purpose web GIFs |
| 64 / 32 colors | Visible banding, posterized look | UI screencaps, logos, simple line art |
| 16 / 8 colors | Stylized, very small | Pixel art, icons, retro looks |
| 10 FPS (recommended) | 100 ms/frame; safe for all browsers | Document flipbooks, slideshow scans |
| 25 FPS | 40 ms/frame; smooth motion | Time-lapse, microscopy loops |
| 50 FPS | 20 ms/frame; max usable rate | Action/motion GIFs in Chrome/Firefox |
| >50 FPS | Clamped to 100 ms in Safari/IE | Avoid — playback is inconsistent |
GIF is limited to 256 colors per frame from the GIF89a spec, while your TIFF likely carries 8-bit or 16-bit per channel (millions to trillions of colors). The conversion has to quantize the palette and that always introduces banding in gradients and skin tones. Pick Colors → By Color Reduction + Dither at 256 colors to soften the transitions; dithering trades a noisy grain pattern for visible bands, which usually reads better at small sizes.
Each Image File Directory (IFD) inside the TIFF becomes one frame of the animated GIF. The order follows the IFD order in the file, which is usually the original scan order. If you have a single-page TIFF, the output GIF is a single static frame — the format still works, but there's no animation to play.
Chrome and Firefox honor frame delays down to 20 ms (50 FPS). Safari (and older Internet Explorer) clamps any delay below ~60 ms up to 100 ms, capping playback near 10 FPS regardless of what the GIF asked for. If cross-browser smoothness matters, set FRAMERATE to 10 FPS so every browser plays it the same; if you only care about Chrome/Firefox, 25-50 FPS is fine.
Mostly yes. TIFF supports a true 8-bit alpha channel with 256 levels of partial transparency; GIF only supports binary transparency — each pixel is either fully visible or fully clear. Soft edges, anti-aliased text, and drop shadows will get a hard outline against whatever background the GIF is composited onto. For real alpha, convert to PNG or WebP instead.
There's no hard per-file limit advertised, but practical browser memory caps and processing time make multi-gigabyte TIFFs (high-resolution scientific scans, gigapixel images) impractical. For typical use — document scans, photo sequences, microscopy stacks under a few hundred MB — uploads complete in seconds to a minute. If a very large file fails, downsample first with Resize TIFF or split the stack.
Both work, but they shrink different things. Cutting colors from 256 to 64 typically halves the LZW-compressed size with most of the perceptual hit going to gradients. Downscaling from 1080p to 720p cuts pixel count by 56% and usually halves size too, but text and fine detail go soft. For document flipbooks, downscale first; for photographic/microscopy content, drop colors first.
Yes. Upload the sequence as a batch — files are read in alphabetical order, so name them frame_001.tif, frame_002.tif, etc. so they animate in the order you intend. Each TIFF becomes one GIF frame using your selected FRAMERATE.
The dominant size driver in animated GIF is frames x pixels x palette entropy. Long sequences (50+ frames), high resolutions (1080p+), and photographic content with full 256-color palettes blow up fast — a 5-second 1080p GIF at 30 FPS easily hits 20-40 MB even after LZW. Cut to 480p or 720p, drop to 10-15 FPS, and reduce the palette to 64-128 colors with dithering. If size still matters, an MP4 or WebM version is 10-50x smaller — see TIFF to MP4 or TIFF to WebM.
No. GIF's 256-color quantization is inherently lossy relative to TIFF's deeper color depth, even before any quality/dither setting. The animation timing and frame count are preserved exactly; the per-pixel color is approximated.