PDF vs TIFF productions: which, and when

The decision is about the recipient’s software

Strip away the tradition and the question is narrow: what can the party receiving this production actually load?

If they are reading documents — attaching them to motions, handing them to a witness, putting them in front of a judge — PDF is the answer and imaging is pure overhead. If they are ingesting into a review platform with a specification, the specification governs and it may well say single-page TIFF with a Concordance load file.

Everything else in this article is downstream of that one question, and the question is answered by asking, not by inferring from the format of the request.

What each format actually gives up

PDF keeps text as text. The production is searchable on arrival without anyone delivering extracted text separately, and it paginates predictably. It accepts a Bates stamp identically to an image. Its disadvantage is that a PDF is a container that can hold live content, which is precisely the property imaged production was adopted to eliminate.

TIFF is inert. Every page is a picture, so what the receiving party sees is permanently fixed and identical to what you sent. Nothing recalculates, nothing links out, nothing carries revision history. Its disadvantages are that it is not searchable without accompanying extracted text, the files are larger, and the multi-page-versus-single-page question adds a processing step.

Neither is the native. Both are renderings. The formulas in a spreadsheet, the tracked changes in a document, the transport headers on an email — none of that survives either format, which is why native production exists as a third category and why protocols carve out specific file types.

Where each one is clearly right

Produce PDF when:

• The documents are going to humans — exhibits, motion attachments, deposition material.
• The production is small enough that a load file would be ceremony.
• The receiving party’s platform ingests PDF, which most current ones do.
• Speed matters and nobody has specified otherwise.

Produce imaged TIFF when:

• A protocol or order specifies it. This is the real reason, most of the time.
• The receiving platform genuinely requires single-page images with an OPT file.
• There is a specific concern about live content that images resolve.

Produce natives when:

• The file type is one where imaging destroys the substance — spreadsheets above all.
• The native form is itself in dispute.
• The protocol carves it out, which most protocols do for spreadsheets and presentations.

Email-specific wrinkles

Email behaves differently from the scanned paper both formats were designed around, and the differences hit imaged productions harder.

Pagination is manufactured. A scanned page exists; a rendered email page is created by the render. Two tools paginate the same message differently, so the whole set has to go through one pipeline or the page counts in the load file will not match the images.

Colour is more often material than people assume. Bitonal imaging is the default in many protocols and it destroys tracked-change markup, highlighted text, and colour-coded cells pasted into a message body. Where the protocol permits colour for relevant documents, email is frequently where to use it.

Threads duplicate at scale. Imaging every message in a quoted thread images the same content repeatedly, and the receiving party pays to review it repeatedly. Thread suppression before imaging is worth more than any format decision.

Attachments are separate documents. Whether they are imaged with the parent, produced natively, or both, the parent-child relationship has to survive — see parent-child email productions.

Cost, honestly

For a small production the format decision is not really a cost decision. Both are a conversion run and a stamping pass.

Where the cost appears is in everything imaging drags behind it. Single-page splitting. Load-file construction with field ordering and delimiters that platforms reject unhelpfully. Extracted text delivered as per-document files. Placeholder pages for natives. None of that is difficult and all of it is work that PDF simply does not require.

So the genuine economic argument is not “TIFF is expensive”. It is that producing imaged TIFF when the recipient would have accepted PDF buys nothing and costs a processing chain.

Settle it early, in writing

The expensive failure is discovering the format requirement after the set has been converted, numbered and logged. Re-formatting means re-imaging, and re-imaging means re-stamping, which means the numbers in your privilege log no longer point at anything.

One email at meet-and-confer — what does your platform ingest, what resolution, single-page or multi-page, which types do you want native — prevents all of it. Where the other side has no answer, produce PDF and say so in the cover letter.

What this pipeline does

EML Exhibit renders .eml messages to paginated PDF on every plan, and to multi-page TIFF at 150 to 600 DPI on Pro. Both outputs carry the From, To, CC, Date and Subject block above the body, and both extract attachments as unmodified originals rather than flattening them into the render.

What it does not do is split multi-page TIFFs into single-page images, build load files, or apply Bates numbers. Those are the downstream steps, and on an imaged production they are where most of the work lives.

Doing it in EML Exhibit

1. Ask what the receiving platform ingests

   Most current review platforms accept PDF. If theirs does, producing PDF removes the imaging step, the single-page split, and a category of load-file problems, at no cost to either side.

2. Read the protocol if there is one

   An agreed protocol specifies format, resolution, colour depth, load-file structure and native carve-outs. Where it exists it governs, and guessing costs a full re-run of everything downstream.

3. Decide native carve-outs explicitly

   Spreadsheets and presentations are conventionally produced natively even in imaged productions, because imaging destroys formulas and speaker notes and often runs off the page.

4. Produce in one pass at the agreed spec

   Render the whole responsive set with one tool at one resolution. Mixed rendering produces inconsistent pagination, which breaks reconciliation after stamping.

5. Deliver extracted text with images

   An imaged set is not searchable on its own. Extracted text from the native messages travels alongside it and is what makes the production usable in the receiving platform.