TIFF Structure Inspector

They are the first two bytes of the file and they set the byte order for every multi-byte value after them: II is little-endian (Intel), MM is big-endian (Motorola). TIFF is the rare format that lets the writer choose, so a reader cannot hard-code either one. The failure is silent rather than loud — read a little-endian ImageWidth of 40 as big-endian and you get 10240, a plausible-looking number that sends a decoder off to allocate a buffer forty times too wide and then fail somewhere far from the actual mistake. That is why the byte-order mark is the first thing this tool shows, along with whether it matches the machine you are reading on.

Almost certainly not. A TIFF is a chain of directories and each one is a page, which is exactly how fax machines and document scanners store a multi-page job in a single file. Nothing in the format requires a reader to follow the chain past the first link, and most previewers, thumbnailers and every browser stop there. If the chain table here lists five pages, the pages are in the file and the reader is the problem — ImageMagick, libtiff's tiffsplit, Photoshop and most PDF converters will walk it.

Strips cut the image into horizontal bands of RowsPerStrip whole rows; tiles cut it into rectangles, and every tile is stored at full size even at the right and bottom edges, where it carries padding that no reader displays. Strips are what a scanner or a straightforward encoder writes, and they let a reader stream the file top to bottom. Tiles exist for large images: a viewer that wants one region of a 30000-pixel-wide scan reads the handful of tiles covering it and never touches the rest. The cost is that tiled files defeat naive readers — plenty of code handles StripOffsets and simply has no branch for TileOffsets.

Because LZW and PackBits both encode repetition, and a photograph or a scan with sensor noise has almost none. PackBits in particular has a worst case that adds one byte per 128, and LZW's dictionary can spend more bits on a noisy run than the run itself occupied. It is a real result, not an error: the ratio here is the sum of the strip or tile byte counts against width x bits-per-pixel-row x height, both read from this file. If you see it on a photographic image, Deflate usually does better, and for continuous-tone material JPEG-in-TIFF or a different format does better still.

Each directory entry is twelve bytes: two for the tag, two for the type, four for the count, and four for the value. If the value needs four bytes or fewer — one LONG, two SHORTs, a three-character ASCII string — it is written into those last four bytes and nothing else in the file moves. If it needs more, those four bytes become an offset and the value is written somewhere else entirely. That is why a TIFF's data is not contiguous with its directory, and it is also the clearest single difference in BigTIFF, where the field is eight bytes wide: a three-SHORT BitsPerSample is out of line in a classic TIFF and inline in a BigTIFF of the very same image.

BigTIFF is TIFF with 64-bit offsets, invented because a classic TIFF's four-byte offsets put a hard 4 GB ceiling on the file — a limit that satellite imagery, whole-slide microscopy and large-format scans hit routinely. It announces itself with magic 43 instead of 42, then two extra header fields, and it changes the directory layout: eight-byte entry counts, twenty-byte entries, eight-byte offsets everywhere. This tool reads that structure in full rather than merely identifying it, so a BigTIFF's chain, entries, strips and tiles are listed exactly as a classic file's are. The only limit is that offsets beyond 2^53 cannot be represented exactly in JavaScript, which no real file approaches.

The preview asks the browser to decode the file, and Chrome, Firefox and Edge carry no TIFF decoder at all — only Safari does, for historical reasons. A failure there says nothing about the file, so it is reported as what it is rather than shown as an empty frame, and everything else on the page is read from the bytes and does not depend on it. As for tags: this tool deliberately stops at the container. It will tell you an Exif or GPS sub-directory exists, where it starts and how many entries it holds, and how many bytes an ICC profile occupies, but the camera, lens, exposure and coordinates inside them are the Exif viewer's job.