TIFF

Yes. TIFF is explicitly recognized by FADGI (the Federal Agencies Digital Guidelines Initiative, hosted by the Library of Congress) and used by libraries, museums, and government agencies as the preservation format for scanned and photographic masters.

No. Unlike JPEG, PNG, or WebP, TIFF is not one of the image formats any major browser — Chrome, Firefox, Safari, or Edge — decodes and renders inline via a standard img tag; a raw .tif URL typically triggers a download prompt or shows nothing at all instead of a picture. Because of this gap, a DAM can never serve TIFF masters directly to a browser and must always generate a converted derivative, such as JPEG or WebP, for any web-facing preview or delivery.

TIFF natively and reliably carries EXIF, IPTC-IIM, XMP, and ICC profiles per image file directory — the broadest and most robust metadata support of any format in this comparison, since the EXIF spec itself is built on TIFF's tag structure.

TIFF's compression isn't fixed to one scheme — it spans both lossless and lossy options. At one end sits uncompressed storage, which preserves every pixel exactly but produces the largest files. LZW is TIFF's classic lossless compressor, shrinking file size with zero quality loss, and Deflate/ZIP offers a similar lossless alternative, sometimes with slightly better ratios. PackBits and CCITT Group 3/4 add further lossless choices suited to simple or bitonal scans. Later extensions also let a TIFF container hold lossy JPEG-compressed data internally, so the same format can serve archival-grade lossless masters and smaller, lossy delivery files.

Yes — because EXIF, IPTC, and XMP can all coexist in the same TIFF, they can drift out of sync across resaves, such as a stale IPTC caption sitting next to an updated XMP keyword list. A DAM needs a clear policy for which field wins.

Yes — TIFF can carry independent metadata per page in a multi-page document, and layered TIFFs (an Adobe/Photoshop-specific extension, not part of core TIFF 6.0) preserve editable structure similarly to PSD.

TIFF supports an unusually wide range, from 1-bit bitonal scans up to 48-bit RGB and CMYK. In practical terms, individual channels can be stored at 8-bit or 16-bit precision — double what JPEG's fixed 8-bit ceiling allows — and the TIFF spec even permits 32-bit-per-channel encoding for specialized scientific or HDR work. That headroom matters for archival masters: capturing scans at 16-bit per channel preserves far more tonal detail, leaving room for future color correction or reprinting before banding or clipping becomes visible.

The typical pattern treats the TIFF as a fixed, non-negotiable archival or print master: once ingested, the DAM stores the original file untouched, without recompressing or altering its pixels, so it stays usable for high-resolution reprints or future restoration work. On ingest, the system automatically generates one or more lossy web derivatives — typically JPEG or WebP — sized and compressed for browser preview, thumbnails, and everyday delivery, since the browser can't render the TIFF itself. Users and downstream systems interact with those lightweight derivatives day to day, while the master TIFF sits untouched in storage as the permanent source of truth.