TIFF file format
Tagged Image File Format, a flexible raster container used in scanning and print.
- MIME type
- image/tiff
- Extensions
- .tif, .tiff
- Category
- Images
Magic-number signature
| 0x00000000 | 49492A00 | II*· | 'II' little-endian + 42 |
Big-endian TIFF starts with 4D 4D 00 2A ('MM' + 42) instead.
About the TIFF format
TIFF is a tag-based container that can hold multiple images, layers and arbitrary metadata, favoured in publishing and document scanning. The first two bytes declare byte order — II for little-endian, MM for big-endian — followed by the magic number 42. Everything else in the file is reached by following offsets: the header points at an image file directory, each directory is a list of twelve-byte tag entries and a pointer to the next directory, and each tag either holds its value inline or points somewhere else again. That design is why TIFF outlived its contemporaries and why no two TIFF files are structurally alike.
Header layout, byte by byte
| Offset | Length | Field | Meaning |
|---|---|---|---|
| 0 | 2 | Byte order | 49 49 for II, little-endian, or 4D 4D for MM, big-endian. It governs every multi-byte number in the entire file including the two bytes immediately after it, so this is the one field that must be read before anything else can be interpreted at all. The catalog signature lists only the little-endian form because a two-way signature cannot be expressed as fixed bytes. |
| 2 | 2 | Version number | The number 42, written 00 2A in a big-endian file and 2A 00 in a little-endian one. It is not really a version — it has never changed — it is a second magic number that also proves the byte order at offset 0 was honest. The value 43 instead means BigTIFF, a different header layout entirely. |
| 4 | 4 | Offset of the first image file directory | Where IFD0 begins, counted from the start of the file. Nothing requires it to be small: writers are free to put the directory after the pixel data, and macOS sips routinely does, so a file whose header points thousands of bytes forward is completely normal. The offset must be even and must not be zero. |
| 8 | variable | First byte after the header | Offset 8 is the earliest position an IFD may legally occupy and a common one, but it is only where the header at offset 4 happens to point. An IFD itself is a 2-byte entry count, then that many 12-byte entries — tag, type, count, then either the value inline or an offset to it — and finally a 4-byte offset to the next IFD, or zero to end the chain. |
| 4 | 2 | Offset byte size — BigTIFF only | When offset 2 reads 43 rather than 42 the header is eight bytes longer and this field holds the size of a file offset, always 8. Reading a BigTIFF as a classic TIFF makes this field look like the low half of an IFD pointer and sends the parser somewhere meaningless. |
| 6 | 2 | Reserved — BigTIFF only | Always 00 00. Together with the field before it, this is what a classic-TIFF reader would have consumed as its four-byte IFD offset, which is precisely why BigTIFF changed the version number instead of trying to stay compatible. |
| 8 | 8 | First IFD offset — BigTIFF only | A 64-bit offset, which is the whole point of BigTIFF: classic TIFF cannot address anything past four gigabytes. BigTIFF directory entries are twenty bytes rather than twelve, with 64-bit counts and values, so the two layouts share nothing beyond the first two bytes. |
Telling it apart from its neighbours
| Easily confused with | How to tell |
|---|---|
| Big-endian TIFF | The catalog signature only covers 49 49 2A 00. A big-endian file is 4D 4D 00 2A and is equally valid and equally common, since scanners and prepress software from Motorola and Sun lineage default to it and Exif inside JPEG frequently uses it too. Any detector that matches only one of the two will call half the world's TIFFs unknown. |
| JPEG | Not a competitor but a container relationship worth recognising in a hex dump: the Exif block inside a JPEG is a complete, self-contained TIFF structure. In a camera JPEG you will find 49 49 2A 00 or 4D 4D 00 2A at offset 12, six bytes after the ASCII Exif and two NULs. Every offset in that structure is relative to the TIFF header, not the file, which is the classic reason a hand-written Exif parser reads garbage. |
| DNG | DNG, NEF, ARW, ORF and most other raw formats are TIFF files at the byte level and will parse cleanly with a TIFF reader; what identifies them are tags inside IFD0, such as DNGVersion (0xC612) for DNG. Canon's CR2 is the exception that marks its own header, placing the ASCII CR and a version pair at offset 8 where a plain TIFF would have its first directory — a layout documented from reverse engineering rather than by Canon. |
| BigTIFF | One byte. Read the version field at offset 2 in the byte order the file just declared: 42 is classic, 43 is BigTIFF. Anything storing whole-slide microscopy, satellite imagery or a large OME-TIFF stack will be the latter, and a classic-TIFF reader given one does not produce a wrong image, it produces a nonsensical IFD offset and an error. |
How these files break
- Truncation, which behaves the opposite way round from most formats here. When the writer placed IFD0 after the pixel data — a legal and common choice — a truncated TIFF loses its entire directory while keeping every scanline, so the file is unopenable despite the image being fully present. Rebuilding means guessing width, height and bit depth and reconstructing a directory by hand.
- An IFD offset that points past the end of the file. The header is perfect and the reader has nothing to work with, producing the unhelpfully generic message that the file is not a TIFF. This is what a partially uploaded or wrongly concatenated scan usually looks like.
- The byte-order bytes rewritten or lost. Flip II to MM and the version number stops reading as 42, so the file is rejected immediately; keep the version readable but misinterpret the order elsewhere and every width, height and offset in the file becomes an astronomically large number.
- StripOffsets left stale after an edit. The directory says where each strip of scanlines lives, and a tool that rewrites the image data without updating those tags produces a file that opens, reports the right dimensions, and then paints bands from the wrong parts of the file — recognisable as horizontal blocks of the picture in the wrong order.
- A tag value that overlaps the header. Any value longer than four bytes is stored elsewhere and referenced by offset, and a writer with an off-by-one in its offset table can point a tag at the header itself. The file passes structural validation and the metadata reads as nonsense.
Where the format stands today
TIFF is what you use when the file has to survive, not when it has to be delivered. Document scanning and archival imaging standardised on it decades ago because it holds multiple pages in one file, stores lossless CCITT Group 4 for bilevel scans, and lets an institution attach whatever custom metadata its catalogue needs without breaking other readers. Prepress and print kept it for CMYK, spot colours and embedded ICC profiles that JPEG cannot express. Photography kept it because Adobe's DNG raw format is a TIFF, so every raw file from a modern camera is one in disguise. Science kept it hardest of all: GeoTIFF adds coordinate reference systems for satellite and mapping data, and OME-TIFF and BigTIFF carry microscopy stacks well past the four-gigabyte limit of the original design. What it has never been is a web format — no browser will display one — and its flexibility is genuinely a liability, since a valid TIFF may use any of a dozen compressions and a dozen colour models, and software that claims TIFF support usually means it supports the two or three variants its author met.
Open TIFF files on this site
Every one of these runs in your browser — the file never leaves your machine.
Related formats
Formats that are easy to confuse with TIFF — compare their leading bytes.