TIFF vs PDF for Document Production: Which to Send

On TIFF vs PDF for document production, send whichever the request, protocol or agency specification names. If nothing names a format, single-page TIFF images with text files and load files suit a recipient loading a review platform, and searchable PDFs, one per document, suit a small set that people will read in a PDF viewer.

The two are different ways of packaging the same pages, and each puts the text in a different place. This post explains the difference, why TIFF persists, when PDF is the better answer, and what conversion between them involves. It is about handling documents and is not legal advice. The parties' agreement and the court's orders decide the form in any given case.

What is the difference between a TIFF and a PDF production?

A TIFF production delivers every page as its own image file, with the text in separate files and load files that tie pages into documents. A PDF production delivers one file per document, with the page images and usually a text layer inside it. The pages look the same. The packaging and the text handling differ.

Side by side:

TIFF is an image format and nothing more. The Library of Congress describes TIFF, Revision 6.0 as "a tag-based file format for storing and interchanging raster images". It stores pixels. A TIFF can hold several images in one file, and the same description notes there is no limit to the number of subfiles a TIFF file may contain, which is why "multi-page TIFF" exists.

A PDF is a container. It can hold page images, real text, both together, bookmarks and more. A PDF made by a scanner holds only images, and it becomes searchable when OCR adds text behind them. How that layer is built is explained in the guide on how to make a scanned PDF searchable.

So the phrase "TIFF production" is shorthand for a whole delivery: images, text and load files. "PDF production" can mean a folder of PDFs and a cover letter, or PDFs accompanied by a load file. When someone proposes either, ask which they mean.

Why do production specifications still ask for single-page TIFF?

Specifications ask for single-page TIFF because the format does one thing predictably. Each file is one fixed picture of one page, named by one Bates number, in a compact black-and-white encoding that dates from the fax era. Nothing in it can be edited, hidden or reflowed. The habit persists because the workflows built around it still work.

The reasons, taken one at a time.

One file, one page, one number. When each page is its own file named with its Bates number, any page can be found, replaced or cited without opening a document. A clawback of page ABC0001234 is the removal of one file.

The image is fixed. A TIFF page is pixels. A stamped number or a redaction box is part of the picture, with nothing underneath and no document properties travelling with it. That is reassuring to a producing party, although a PDF can be flattened to the same effect.

The encoding is small and old. The Library of Congress entry for TIFF with Group 4 compression explains that this subtype wraps a bitmap compressed with a scheme taken from Group 4 facsimile standards, and is "thus limited to bitonal imaging, suitable for the reproduction of typographic or line-art originals." Bitonal means each dot is black or white. Typed pages compress very well that way. The parent format's current revision was published in 1992, so tools have had a long time to agree on how to read it.

Written standards name it. The SEC's Data Delivery Standards say that in an imaged production "black and white images must be 300 DPI Group IV single-page TIFF files" and that "all image files must have a unique file name, i.e. Bates number". Once a format is written into a standard that producing parties must follow, the tools and habits built to meet it stay in use.

The load file assumes it. The image cross-reference file lists one line per image file and flags which lines begin a new document, so it needs page-level files to point at. The section on what the OPT file adds shows the layout.

None of this makes TIFF better for every case. It makes TIFF the safe default for a recipient whose process is built on it. A recipient with no such process gets a folder of thousands of files that no ordinary program presents as documents.

Send the format the production request names. Single-page TIFF with a load file is one way to deliver electronically stored information from a paper set. A searchable PDF keeps the image and the text in one file, which helps when the recipient is not loading a database. If the request is silent on form, ask which one they will import, and send that form.

Where does the OCR text live in each production format?

In a TIFF production the text lives outside the images, in plain text files, normally one per document, that a load file points to. In a searchable PDF production the text lives inside each PDF as a hidden layer behind the page image. Neither format improves the OCR. They store the same recognized words in different places.

Text beside the images

An image cannot hold searchable words, so the text is delivered as its own file. A specification says how. One arrangement is a text file for each document, named to match the document's first page. The SEC's standards take that approach: text "must be produced as separate document-level text files, not as fields within the .DAT file", and each text file "must be named after the FIRSTBATES". The data load file then carries a column with the path to each text file.

Consequences for you as the producing party:

• You need text per document, which means you must know your document boundaries before you make the text files.
• Text files are easy to open and check in bulk. A zero-byte file stands out in a folder listing.
• Text and image can drift apart. If a page is replaced or redacted and the text file is not remade, the two disagree and nothing on screen warns you.

Text inside the PDF

A searchable PDF carries its text with it. The recipient needs no load step: open the file, press Ctrl+F. The text cannot be separated from its pages by a bad file path.

Consequences:

• Quality is harder to audit in bulk. To see what the layer says, you select and copy text or extract it with a tool.
• How precisely the text sits over the words varies by the software that made the layer. Some place each word exactly. Others attach a page's text to the page as a block, so a search finds the right page and the highlight may be off. Schema Law's searchable PDF export is of the second kind, as the note in the post on searchable PDFs for court filing explains. Test a sample in the recipient's likely viewer.
• A redaction must remove the layer's words as well as cover the image. That is true of text files too, but in a PDF the leftover words are inside the very file you are sending.

Either way, make the text last, from the final stamped and redacted pages, and open a sample before delivery.

When a searchable PDF production is the better choice

A searchable PDF production is the better choice when the set is small, the documents came from paper, the recipient will read them in a PDF viewer, and no order or specification requires images with load files. In that situation PDFs give the recipient usable, searchable documents with no loading step and give you fewer files to get wrong.

Signs that PDF fits:

• Size. A few hundred or a few thousand pages. People will open these one at a time.
• No review platform on the other side. A solo practitioner or small firm, a self-represented party, or a recipient who has said they work in a PDF viewer.
• Paper sources. There is no metadata to deliver, so the data file in a load-file production would be nearly empty.
• Color and photographs. A PDF holds color pages and black-and-white pages together without a second image format.
• An agreement. The other side has agreed in writing, or the protocol lists searchable PDF as an accepted form.

Signs that it does not:

• A written specification names TIFF. Follow it or negotiate before producing.
• The recipient will load the set into a platform alongside email and other electronic data, and wants everything in one structure.
• The set runs to tens of thousands of documents, where a structured load is quicker for everyone.

An agency may allow PDF on conditions. The SEC's standards permit Adobe PDF production "with prior approval", and then require that the PDFs be "unitized at the document level, i.e., each PDF must represent a discrete document", that they contain embedded text covering "all discernible words within the document", and that Bates-endorsed PDFs "be named by the Bates range." Those three conditions are a good checklist for any PDF production: one document per file, real text throughout, names tied to the numbering.

A worked choice. A fictional landlord, Brightwater Holdings, must produce 1,900 pages of paper lease files to a tenant represented by a two-lawyer firm. The requests say nothing about format. The lawyer emails opposing counsel proposing "searchable PDFs, one per document, Bates-stamped BWH, named by beginning Bates number", and gets a one-line agreement. That email goes in the production file. Had the tenant's counsel replied with a vendor's specification asking for TIFF, text and load files, the conversation would have been about that specification instead.

How to prepare the set itself, including the privilege screen and the pre-delivery check, is in the guide on how to produce scanned documents in discovery. If you are the one receiving PDFs and loading them somewhere, the post on OCR before uploading to a review platform covers what happens to them on intake.

Converting a scanned PDF set to TIFF and text, or back again

Converting between the two is two separate jobs: changing the image container, and placing the text. PDF to TIFF means writing each page out as an image file and exporting each document's text to a text file. TIFF to PDF means combining a document's page images into one PDF and running OCR on it.

From scanned PDFs to TIFF, text and load files

1. Finish the PDFs first. Unitize, stamp and redact while each document is still one file. It is far easier than working on loose pages.
2. Write out page images. Some PDF editors can save or export a PDF as TIFF, one file per page, and imaging utilities do the same in bulk. Choose black-and-white Group 4 for typed pages and whatever the specification says for color.
3. Name each image by its Bates number. Pad with zeros so files sort correctly.
4. Make a text file per document. Run OCR on the final PDF and export plain text. Name the text file after the document's first Bates number.
5. Build the load files that list the documents and point to the images and text.
6. Check counts. Image files equal total pages. Text files equal total documents.

Where Schema Law fits is step four only. It accepts PDF, PNG and JPEG uploads and does not accept TIFF, and it does not export TIFF: the eight export formats are Word, Excel, CSV, JSON, searchable PDF, plain text, Markdown and HTML. So you would upload each final PDF, export plain text for the text folder, and make the page images in other software. Schema Law does not produce load files or custom layouts on any plan, and the pricing page shows what each plan does include. Building the load files yourself is covered in the guide on how to create a load file from scanned PDFs.

From TIFF back to searchable PDF

A received TIFF production can be turned into PDFs for reading:

1. Group the pages into documents using the image cross-reference file, which marks each document's first page.
2. Combine each group into one PDF in page order. PDF editors and imaging utilities both do this.
3. Use the text that came with the set if it is good. If it is missing or poor, run OCR on the combined PDF.
4. Keep the produced files untouched and work on copies.

If your OCR tool takes PDF and common photo formats but not TIFF, as Schema Law does, the combining step has to come first. Which image types OCR tools accept, and what to do with the ones they do not, is covered in the post on which image file types OCR can read as text.

What conversion cannot fix

Conversion changes the container, not the picture. A page scanned at low resolution stays blurry in either format. Converting a color page to bitonal TIFF throws away the color for good, and can turn a light gray stamp or pencil note white. Go back to the original scan if a converted page has lost something.

Color pages, file size and page counts in TIFF and PDF sets

Color is the main practical cost in a TIFF set, because Group 4 TIFF is black and white only and color pages must travel as a second image type. File size rarely decides anything for typed pages. File counts do: a TIFF set has a file for every page, a PDF set one for every document.

Color. Bitonal TIFF cannot show a yellow highlight, a red-ink correction, a colored chart or a photograph in a way anyone can read. Specifications handle this by naming a second format: the SEC's standards say "color images must be produced in JPEG format". A TIFF production of mixed paper therefore has two image types in one folder structure, and someone has to decide page by page which is which. Rules of thumb for that decision:

• Keep color where it carries meaning: highlighting, colored ink, charts keyed by color, photographs, maps.
• Bitonal is fine for ordinary typed pages on white paper, including letterhead with a colored logo, unless the protocol says otherwise.
• When in doubt on a page that matters, keep the color and say so in the cover letter.

A PDF set avoids the split, since each page inside a PDF can be color, gray or black and white.

File size. Typed black-and-white pages are small either way. Color and grayscale pages are many times larger in either format. Size limits matter at the edges: a transfer service's cap, an email attachment limit, or an upload limit on a tool you use along the way. Schema Law's upload limit is 20 MB per file, so a long color PDF may need splitting before conversion.

Counts. Compare what each form of the same paper set looks like on disk, using a fictional 500-document, 6,000-page production:

Folder caps are real: the SEC's standards say "the number of image files per folder should not exceed 2,000 files", and set the same figure for text folders. A 6,000-page set under that rule needs at least three image folders, and the load file paths must match them exactly.

More files mean more ways for one to go missing, and also finer control when one page must be replaced. That trade is the whole choice in miniature. If the recipient has a platform and a specification, the structure of TIFF serves them. If the recipient has a PDF viewer and a deadline, 500 searchable PDFs are the form they can use the day the set arrives.