TIF File Documentation
Summary
A .tif file is a Tagged Image File Format (TIFF) image: a high-quality raster format most often used for scanned documents, faxes, photos, and archival or prepress masters. .tif and .tiff are the same format, just two spellings. It stores pixels described by numbered tags in an Image File Directory, supports lossless compression, and can hold many pages in one file. It opens in Windows Photos, macOS Preview, and almost any image app. MIME: image/tiff.
Technical details
| Feature | Value |
|---|---|
| Full name | Tagged Image File Format |
| File extension | .tif, .tiff (identical format) |
| MIME type | image/tiff |
| Developer | Aldus (1986); owned by Adobe since 1994 |
| Introduced | 1986; TIFF 6.0 specification 1992 |
| Standard / spec | Adobe TIFF 6.0 |
| Open standard | Yes — publicly published |
| Format type | Tag-based raster image container |
| Binary | Yes |
| Byte order | Declared per file: II little-endian or MM big-endian |
| Magic number (hex) | 49 49 2A 00 (II) or 4D 4D 00 2A (MM) |
| Colour depth | 1 to 32 bits per channel; grey, RGB, CMYK, indexed, Lab |
| Compression | None, LZW, PackBits, ZIP/Deflate, CCITT G3/G4, JPEG |
| Alpha channel | Supported (ExtraSamples tag) |
| Multi-page | Yes — multiple IFDs in one file |
| Pixel layout | Strips or tiles |
| Metadata | EXIF, XMP, IPTC, ICC colour profile, GeoTIFF geo-tags |
| Notable variant | GeoTIFF (georeferenced imagery); BigTIFF (64-bit offsets) |
| Related extensions | .tiff, .geotiff, .btf, .nef, .cr2, .dng |
| Common conversions | TIF → PDF (multi-page scans), → JPG (shrink) |
| Specification URL | adobe.io/open/standards/TIFF.html |
What is a TIF file?
A .tif file is a Tagged Image File Format (TIFF) image, a raster format Aldus created in 1986 to standardise the output of the desktop scanners then arriving with the first Macs and PCs. The current TIFF 6.0 specification dates to 1992, and Adobe has owned and published it since acquiring Aldus in 1994. TIFF became the archival and prepress standard because it is lossless, high-bit-depth, colour-managed, and extensible, and because a single file can hold many images, which makes it the natural container for multi-page scanned documents and fax pages. The .tif and .tiff spellings are the identical format; the three-letter form is only a relic of the DOS 8.3 filename limit.
What makes TIFF distinctive is that it is not one fixed layout but a tagged container. An image is described by a dictionary of numbered tags (width, height, bit depth, compression, colour space), and a reader assembles the picture from whichever tags are present. That design is the source of both TIFF’s longevity and its occasional interoperability headaches. The sections below work through the actual bytes: the byte-order header, the Image File Directory and the structure of a tag entry, the tags that matter most, how pixels are stored in strips or tiles, the compression schemes, and the multi-page and GeoTIFF extensions.
The header: byte order, magic 42 and the first IFD
Every TIFF opens with an 8-byte image file header, and its first job is to declare byte order, because TIFF files exist in both endiannesses.
Offset Size Field
0 2 byte order: "II" (0x4949) little-endian, or "MM" (0x4D4D) big-endian
2 2 42 (0x002A), written in the declared byte order -> confirms TIFF
4 4 offset to the first Image File Directory (IFD)
The II/MM choice (Intel versus Motorola) is not cosmetic: every multi-byte integer in the rest of the file, including all tag values and offsets, is stored in that order, so a parser that ignores the header will read garbage on the wrong-endian file. The constant 42 is a sanity check that the file really is TIFF. The last four bytes of the header are a file offset, not image data: they point to the first IFD, which can sit anywhere in the file. TIFF is fundamentally an offset-linked structure, more like a small on-disk database than a linear stream, which is why images, tags, and pixel data can appear in any order and be reached by following offsets.
The Image File Directory and the anatomy of a tag
The Image File Directory is the heart of TIFF. It describes one image as a sorted list of tag entries, and it ends with an offset to the next IFD (or zero if this is the last image). Its layout is precise.
IFD:
2 bytes : number of directory entries (N)
N x 12 : the tag entries
4 bytes : offset to next IFD (0 = none)
Each 12-byte entry:
2 bytes : tag ID (e.g. 0x0100 = ImageWidth)
2 bytes : field type (1=BYTE, 3=SHORT, 4=LONG, 5=RATIONAL, 2=ASCII ...)
4 bytes : count (number of values)
4 bytes : value OR offset to the values if they don't fit in 4 bytes
The last field of an entry is the clever part. If the tag’s data fits in four bytes (a single SHORT or LONG), the value sits inline; if it does not (an ASCII string, an array, a set of RATIONALs), those four bytes instead hold an offset to where the values live elsewhere in the file. This indirection is what lets a compact directory describe large or variable-length metadata. The entries within an IFD must be sorted in ascending tag-ID order, which lets a reader binary-search for a tag and stop early. A tag a reader does not recognise is simply skipped, so private and newer tags coexist with old readers, the same forward-compatibility principle that keeps decades-old TIFF tools working.
The core tags that define an image
A handful of tags carry the essential description of the pixels. A reader needs these to interpret the image data at all.
| Tag (ID) | Meaning |
|---|---|
| ImageWidth (256), ImageLength (257) | Pixel dimensions of the image. |
| BitsPerSample (258) | Bits per channel, e.g. 8, 16, or 32. |
| SamplesPerPixel (277) | Number of channels (1 grey, 3 RGB, 4 CMYK or RGBA). |
| PhotometricInterpretation (262) | How samples map to colour: 0/1 = greyscale, 2 = RGB, 5 = CMYK, 6 = YCbCr, 3 = palette. |
| Compression (259) | 1 none, 5 LZW, 32773 PackBits, 8 Deflate, 3/4 CCITT G3/G4, 7 JPEG. |
| StripOffsets (273) / TileOffsets (324) | Where the pixel data lives in the file. |
| RowsPerStrip (278) | How the image is divided into strips. |
| XResolution (282), YResolution (283), ResolutionUnit (296) | Physical resolution, e.g. 300 DPI for a scan. |
The PhotometricInterpretation tag is easy to overlook and important: TIFF supports both “0 = white” and “0 = black” conventions for bilevel images, which is why a fax scan can appear inverted in a naive viewer. SamplesPerPixel combined with the ExtraSamples tag is how TIFF signals an alpha channel, and whether that alpha is premultiplied. Because so much depends on reading these tags correctly, a “TIFF that won’t open” is usually a tag or compression combination the specific viewer never implemented, not a corrupt file.
Strips, tiles and where the pixels live
TIFF does not store pixels in one contiguous block. Instead the image is broken into pieces, each independently located and often independently compressed. The classic scheme is strips: horizontal bands of RowsPerStrip scanlines each, with the StripOffsets tag giving the file offset of every strip and StripByteCounts giving each strip’s length. Strips let a decoder read and decompress a large image band by band without loading it whole, and let an encoder stream output. The alternative, added in TIFF 6.0, is tiles: rectangular blocks (for example 256×256) addressed by TileOffsets. Tiling suits very large images and GIS imagery because a viewer can fetch just the tiles covering the visible region rather than whole rows spanning the full width. A single image uses one scheme or the other, signalled by whether the strip tags or the tile tags are present.
Compression: LZW, PackBits, ZIP, CCITT and JPEG-in-TIFF
The Compression tag selects one of several schemes, and the right choice depends on the content. For continuous-tone photos, LZW and ZIP/Deflate give lossless compression (Deflate is the same algorithm used by PNG and ZIP). PackBits is a simple run-length scheme, effective on images with long uniform runs. For black-and-white document and fax scans, CCITT Group 3 and Group 4 are dramatically more efficient because they model long runs of white and black pixels; Group 4 is the standard for archived faxes and bilevel document scans and can shrink a page to a few tens of kilobytes. TIFF can also embed JPEG-compressed data for lossy photographic compression, though the old “JPEG in TIFF” scheme (compression 6) was so troublesome that it was replaced by a cleaner method (compression 7), and legacy files using the old scheme still trip up some readers. This breadth is exactly why one .tif can be a tiny lossless line-art scan and another a huge uncompressed 16-bit photographic master.
Multi-page documents, GeoTIFF and BigTIFF
A single TIFF file can hold many images by chaining IFDs: each IFD ends with an offset to the next, and a zero terminates the chain. This is the mechanism behind multi-page TIFF, the reason a scanned contract or a multi-page fax is one .tif rather than one file per page, and why converting such a file to PDF maps each IFD cleanly onto a PDF page. Two important extensions ride on the tag system without changing it. GeoTIFF adds a small set of private tags (ModelPixelScale, ModelTiepoint, and a GeoKeyDirectory) that pin the pixel grid to real-world map coordinates and record the coordinate reference system, making TIFF the standard container for satellite and aerial imagery in GIS. BigTIFF widens the file’s offsets from 32-bit to 64-bit (signalled by the version number 43 instead of 42 in the header) so a file can exceed the 4 GB limit that ordinary TIFF hits, which matters for high-resolution scientific and mapping imagery.
Frequently asked questions
Is there a difference between .tif and .tiff?
No. They are the same Tagged Image File Format; the byte contents are identical. The .tif spelling is a leftover from the DOS three-character extension limit. Renaming .tif to .tiff (or the reverse) changes nothing about the file.
How does one TIFF file hold several pages?
Each image is described by its own Image File Directory, and every IFD ends with the file offset of the next one, forming a chain terminated by a zero offset. A reader follows the chain to find each page. This multi-IFD structure is why a multi-page scan is a single .tif and why it converts one-to-one into a multi-page PDF.
Why is my TIF file so large?
TIFF is usually lossless and is often stored uncompressed at high bit depth, so a high-resolution scan can be tens of megabytes. Saving with LZW, ZIP, or (for bilevel document scans) CCITT Group 4 compression shrinks it losslessly; converting photos to JPG or multi-page documents to PDF reduces size for sharing.
References
- Adobe — TIFF 6.0 Specification
- Library of Congress — TIFF format sustainability
- LibTIFF — the reference TIFF library
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.