Match every output to its receiving role.
ENG-024_0007.tifPDF is a flexible delivery container
A standard PDF can contain born-digital text, page images, a searchable text layer, or a mixture. For scanned records, it is often useful as an access or review derivative because users can open a multi-page file and search any included OCR text. Its presence alone does not establish that the image quality, OCR, metadata, or repository import requirements have been met.
A searchable PDF should retain the source bitmap image rather than replace it with editable text. National Archives transfer guidance distinguishes searchable PDFs that preserve the original image from transformations that degrade or substitute for the captured content. Define the requested PDF role and any text-layer requirements in the project specification.
PDF/A is a separately validated preservation target
PDF/A is a constrained family of ISO PDF standards intended to support long-term preservation of page-oriented documents and their static visual appearance. It is not simply another name for PDF. Different PDF/A profiles exist, and a file calling itself PDF/A may not be fully compliant without validation.
When PDF/A is requested, identify the required profile, validation method, treatment of OCR text, embedded fonts, metadata, and any destination constraints. Do not call a file PDF/A merely because it is a scan in a PDF container. The target profile and validation responsibility should be explicit.
TIFF is a raster image format
TIFF is a tagged raster-image format commonly used for high-resolution scanned images and, in many Library of Congress workflows, primary or master files. It can be a single image or multi-page file, but it remains an image container. TIFF alone does not provide a searchable text layer, repository index, or successful import.
A TIFF image file can support later derivative creation when that role is requested. The appropriate compression, bit depth, page arrangement, color mode, and metadata are project-specific decisions. The destination system’s supported formats and any records policy should guide the final delivery choice.
| Format | Common project role | Important boundary |
|---|---|---|
| Access, review, or delivery container | May or may not contain OCR or preservation features | |
| PDF/A | Validated preservation-oriented PDF derivative | Requires named profile and validation; not every PDF qualifies |
| TIFF | Raster image master or primary image role when requested | Does not itself create search, metadata, or repository compatibility |
Keep roles and identifiers traceable
A practical package may retain a TIFF image master where requested, make an access PDF or validated PDF/A derivative where specified, provide OCR text separately or embedded where the target accepts it, and retain a metadata record that joins all of those files. The source image, derivative, OCR, and index should share a stable identifier.
Fictional example — no PII: `REC-00817.tif` can be the requested raster source image; `REC-00817.pdf` can be an access derivative; `REC-00817.txt` can hold OCR; and a metadata row can identify the source fiche and frame. The target repository’s actual requirements determine which items are loaded.
Common questions
Is PDF/A always better than PDF?
No. PDF/A has a specific preservation-oriented role and validation needs. An ordinary PDF may be the appropriate access or repository derivative when that is the agreed requirement.
Does TIFF make a collection searchable?
No. TIFF is an image format. Search may require OCR and/or structured metadata in addition to the image file.
Can a repository accept any of these formats?
Not automatically. The selected repository or cloud workflow determines supported formats, metadata requirements, and import rules.
Sources & further reading
These references explain technical formats, standards or destination requirements. They do not imply endorsement of National Microfilm.