Keep the TIFF master and make separate access copies
Use TIFF as an archival or production master when the collection policy, receiving archive, or print workflow asks for it. FADGI calls format selection a project decision with trade-offs among quality, access, and lifecycle management. It also says master files should follow a lossless workflow. [2] The policy comes first; a .tif extension alone does not make a file a preservation master.
Keep that master unchanged. Generate smaller access copies for websites, email, review, OCR delivery, or printing. MDN lists TIFF among formats to avoid for web content and shows direct TIFF image support only in Safari, while JPEG, PNG, and WebP have broad browser support. [4] A derivative improves access without turning the delivery file into the archival source.
Choose compression from the archive policy
Uncompressed TIFF stores a direct raster and usually creates the largest file. LZW and Deflate compress without changing decoded sample values when the receiving system supports them. TIFF 6.0 defines LZW as lossless and notes that its gain depends on image content. [1] CCITT Group 4 targets one-bit document images. JPEG-in-TIFF is lossy and belongs only in a workflow that accepts that trade-off.
Do not turn one institutional example into a universal rule. FADGI's 2023 table for modern unbound textual records accepts uncompressed or Deflate TIFF 6.0, while other material classes and repositories can set different requirements. [2] Record the codec, bit depth, color space, and validation tool in the project profile so another operator can reproduce the choice.
Count image directories before calling them pages
A classic TIFF starts with a byte-order marker, version 42, and an offset to the first Image File Directory (IFD). Each IFD contains tagged fields and a pointer to the next top-level IFD. [1] Following that chain gives a count of main image directories. It does not prove that every directory is a document page: reduced images, masks, or application-specific subimages can also exist.
The PageNumber tag carries a zero-based page number and a total-page value when an encoder supplies it; TIFF also allows pages to appear out of numerical order. [1] Treat the top-level IFD count as a structural check and PageNumber as a stronger page hint. Keep SubIFDs separate because they commonly hold related images rather than another top-level document page.
Estimate storage before the scan starts
Estimate uncompressed raster bytes as width × height × samples per pixel × bits per sample ÷ 8. A 6000 × 4000 16-bit grayscale scan needs 48,000,000 bytes, or about 45.8 MiB, before TIFF directories, strips, metadata, and compression. The same dimensions in 16-bit RGB use 144,000,000 bytes, or about 137.3 MiB.
One hundred grayscale pages at that size total about 4.47 GiB before overhead. Classic TIFF uses 32-bit offsets and reaches a 4 GiB design limit; BigTIFF changes the version marker from 42 to 43 and uses 64-bit offsets. [3] At that scale, split files or use a BigTIFF-aware workflow before capture instead of discovering the limit during final export.
Inspect the header before creating derivatives
Drop a .tif or .tiff into the imgrove Image Size Checker. Its bounded classic-TIFF parser reports stored pixel dimensions, bit depth, samples, compression, photometric interpretation, resolution, top-level IFD count, and PageNumber values. Everything runs in the current browser tab, and the downloadable text report gives the handoff a compact audit record.
The header check does not decode strips or tiles, render pixels, validate an ICC profile, prove archival conformance, or support BigTIFF. Open the master in the archive's approved viewer and run its required fixity and quality checks. Then create the access copy; use Image to PDF only after you have a browser-readable derivative, since the browser does not decode TIFF reliably.
TIFF compression choices for scan masters
| Choice | Best fit | Main trade-off |
|---|---|---|
| Uncompressed | Policies that require direct lossless raster storage | Largest files and highest storage cost |
| LZW | Lossless TIFF when the archive and reader approve it | Compression gain varies with noise and image content |
| Deflate (ZIP) | Lossless projects whose profile explicitly allows Deflate | Compatibility and policy must be confirmed before capture |
| CCITT Group 4 | One-bit black-and-white document images | It does not apply to grayscale or color samples |
| JPEG-in-TIFF | Controlled production workflows that accept lossy pixels | It conflicts with a lossless-master requirement |
Keep TIFF as the master when
- A repository profile names TIFF and its accepted codec
- The scan needs lossless high-bit-depth or color-managed storage
- A separate derivative can serve browser and reader access
Pause the handoff when
- The codec, bit depth, page structure, or color profile is unknown
- A large classic TIFF approaches its 4 GiB offset limit
- The only copy has been overwritten by a compressed access version
Related archive, resolution, and delivery guides
Related imgrove tools
Read the TIFF header before the handoff
Check a classic .tif or .tiff locally for stored dimensions, bit depth, compression, resolution, top-level directories, and page tags. The tool reads bounded header data without decoding image pixels, so keep the master and finish archival validation in the repository's approved software.
Try Image Size CheckerTry the workflow and tell us what worked, what failed, or what needs clearer guidance: hi@imgrove.com.