TIFF Format: Print, Scanning & Professional Use

Origin and design intent

TIFF (Tagged Image File Format) was developed in 1986 by Aldus (later acquired by Adobe) to serve as a common format for desktop scanners. The first specification was designed around a specific industry problem: scanner manufacturers each shipped their own proprietary file formats, and software vendors had to write per-scanner import code. TIFF unified the landscape.

The design priority — and the reason TIFF has endured for almost four decades — is extreme flexibility. A TIFF file can contain:

Lossless or lossy compressed data.
Multiple compression algorithms (LZW, ZIP, JPEG, PackBits, CCITT Group 4 for fax content, plus newer additions).
1-bit through 32-bit-per-channel colour depth.
Multiple colour spaces (RGB, CMYK, LAB, YCbCr, palette, greyscale).
Multi-page or multi-layer content.
Arbitrary metadata via the "tag" system.
Tiled or stripped pixel data for large images.
Sub-files for thumbnail variants, alpha channels, depth maps.

That flexibility is the format's strength and its weakness. TIFF can represent almost any kind of raster image, but two TIFF readers may support different subsets of the specification, leading to compatibility surprises.

The tag system

TIFF's defining technical feature is its tag-based metadata system. Every piece of information in a TIFF file is associated with a numeric tag identifier. The header lists tag/value pairs, and decoders look up the tags they understand.

Common tags include:

256/257 — image width and height.
258 — bits per sample.
259 — compression method.
262 — photometric interpretation (RGB, greyscale, palette, CMYK, etc.).
270 — image description.
271/272 — equipment make and model.
305 — software that created the file.
306 — datetime.
315 — artist.
33432 — copyright.
34665 — EXIF IFD pointer.
34853 — GPS IFD pointer.

The extensibility means new tags can be added for new capabilities without breaking older decoders (which simply ignore unknown tags). This is how TIFF accumulated support for EXIF, GPS, ICC colour profiles, geospatial data (GeoTIFF), and dozens of other extensions.

Compression options

TIFF supports several compression methods within the same container format:

Uncompressed — raw pixel data. Largest files, fastest to read. Used by some scientific and medical pipelines where compression artefacts cannot be tolerated.
LZW — lossless dictionary compression. Same algorithm as GIF. Common default.
ZIP (DEFLATE) — lossless. Same algorithm as PNG. Usually produces smaller output than LZW.
PackBits — simple lossless run-length encoding. Fast, but only effective on content with large flat regions.
CCITT Group 3 / Group 4 — lossless compression specifically for 1-bit (black-and-white) images. Designed for fax and document scanning.
JPEG (in TIFF) — lossy. Allows photographic compression within the TIFF container. Used by some camera RAW workflows and document management systems.

For most contemporary TIFF use, LZW or ZIP are the right choices. JPEG-in-TIFF is occasionally seen but limited in practice.

The professional photography and print workflow

TIFF's enduring role is as the format of choice for professional photography, print production, and any workflow that involves multiple editing passes.

The reasons:

Lossless. A TIFF preserves the source exactly. Re-saving doesn't compound artefacts.
High bit depth. Supports 16-bit per channel, important for editing operations that would clip an 8-bit gradient.
CMYK support. Most other web image formats are RGB-only. CMYK is essential for print preparation.
Layer and alpha support. Photoshop saves a flattened TIFF with extra channels and selection masks intact.
Universal tool support. Every serious image editor reads and writes TIFF.

A typical print-production workflow uses TIFF as the master format and renders to JPEG or PDF for delivery. The TIFF stays in the asset library; the JPEG goes to the printer or website.

Multi-page TIFFs and document scanning

TIFF's support for multiple images in a single file made it the natural format for document scanning. A multi-page scan can be a single TIFF file containing one image per page, often with CCITT Group 4 compression for crisp black-and-white text.

Many document management systems still use multi-page TIFF as their primary storage format. PDF has largely displaced TIFF for distribution (because PDF embeds text searchability and rendering instructions), but TIFF remains common in capture pipelines.

GeoTIFF

GeoTIFF is an extension that adds geospatial referencing tags to TIFF. A GeoTIFF file contains image data (typically a satellite image, aerial photograph, or map raster) plus tags specifying the coordinate system, projection, and geographic bounds.

GeoTIFF is the standard format for geographic raster data in GIS workflows. Tools like QGIS, ArcGIS, and the GDAL command-line utilities read and write GeoTIFF natively.

Browser support

TIFF is not a web format. No major browser renders TIFF natively. Files served as .tiff typically prompt a download dialog or display as broken images.

For web use, TIFF content must be converted to a web-compatible format (JPEG, PNG, WebP, AVIF) before delivery.

When to use TIFF today

Choose TIFF when:

The image is the master copy that will be edited or processed further.
You need lossless storage with full bit depth.
The workflow specifically requires TIFF (print production, GIS, document scanning, medical imaging).
The file needs to carry extensive metadata.
CMYK colour space is required.

Choose other formats when:

The image is for web delivery (WebP, JPEG, AVIF).
The file is final and won't be edited further (compressed formats save dramatically more space).
The recipient lacks TIFF-capable tooling.
Email or document embedding is the destination (use JPEG or PNG).

File size

TIFF files are large by web standards. A 4000×3000 photograph as uncompressed TIFF is 36 MB; as LZW-compressed TIFF, typically 12–25 MB; as JPEG at q=85, 1–3 MB; as WebP at q=80, 600 KB – 2 MB.

This is the right trade-off for master files (where the bytes buy you editing flexibility) and the wrong trade-off for delivery files (where the bytes buy you nothing the user can see).

Conversion guidance

The standard TIFF-to-web pipeline:

Keep TIFF originals in the asset library.
Generate WebP/JPEG/AVIF derivatives for delivery.
Reference the derivatives in HTML; never link to the TIFF directly.

# TIFF to WebP with ImageMagick
convert master.tiff -quality 80 -define webp:method=6 output.webp

# TIFF to JPEG for general distribution
convert master.tiff -quality 90 output.jpg

# Multi-page TIFF to a sequence of WebP files
convert master.tiff "page-%d.webp"

For Node-based pipelines, Sharp handles TIFF input:

import sharp from "sharp";

await sharp("master.tiff")
  .webp({ quality: 80, effort: 6 })
  .toFile("output.webp");

Modern relevance

TIFF matters for:

Professional photography workflows — master file format.
Print production — handoff to commercial printers.
Document scanning and archival — multi-page documents with high fidelity requirements.
Geographic information systems — GeoTIFF for satellite imagery and maps.
Medical imaging — DICOM-related workflows sometimes use TIFF as an intermediate.
Scientific imaging — astronomy, microscopy, and other domains where bit depth and lossless storage matter.

TIFF does not matter for:

Web delivery — browsers don't render it.
End-user consumption — file sizes are too large.
Casual photo sharing — JPEG and HEIC dominate.
Social media — platforms convert everything to their preferred formats anyway.