Discovery & ESI

PDF, Native or Load Files? Choosing a Discovery Production Format

Choosing a production format in discovery: PDF vs native vs TIFF with load files, what the rules require, the right format per data type, and sample wording.

By CourtBriefly Editorial TeamUpdated October 7, 2026 · 8 min read

Quick answer

The right production format in discovery depends on the data and on what the receiving side can use. Searchable PDFs suit small document productions, TIFF images with load files suit review platforms and larger sets, and native files suit spreadsheets, audio, video and other data that cannot be imaged faithfully. Under Rule 34, the requester may specify a form, and the responder must state the form it will use.

Rule 34 lets the requester specify a form; the responder must object and state its own.
Searchable is the baseline: do not degrade data that was searchable in ordinary use.
Load files only help if the receiving side has a platform that reads them.
Spreadsheets, media and messages usually need formats other than flat page images.
Agree on formats before collection, not after the first production.

In this guide

What do the federal rules say about the form of production?
PDF, TIFF with load files, or native: how do they compare?
What is actually inside a load file production?
Which format fits which kind of data?
How should text messages and chats be produced?
Sample format language for requests and ESI protocols
What mistakes force a re-production?
Frequently asked questions

Format fights usually surface after the fact. One side produces a stack of image-only PDFs, the other side expected native files with metadata, and both are now paying to redo work. Choosing a production format in discovery is really a decision about what the receiving party needs to search, sort and verify, and what the producing party can reliably generate.

This guide compares the common formats, explains what is inside a load file production in plain terms, matches formats to data types, covers the special problem of text messages and chats, and closes with sample format language for requests and ESI protocols.

What do the federal rules say about the form of production?

The requesting party may specify a form, the responding party may object but must then state the form it intends to use, and if no form is specified the data comes in the form it is ordinarily maintained or in a reasonably usable form. The key provisions of the Federal Rules of Civil Procedure:

Rule 34(b)(1)(C): a request may specify the form or forms for producing ESI.
Rule 34(b)(2)(D): the response may object to a requested form, and if it does, or if no form was specified, it must state the form or forms the party intends to use.
Rule 34(b)(2)(E)(i): documents are produced as kept in the usual course of business or organized and labeled to correspond to the request.
Rule 34(b)(2)(E)(ii) and (iii): absent a specified form, produce as ordinarily maintained or in a reasonably usable form, and the same ESI need not be produced in more than one form.
Rule 26(f)(3)(C): the discovery plan addresses the form or forms of ESI production.
Rule 45(e)(1)(B) and (C): similar defaults for nonparties responding to subpoenas.

The 2006 advisory committee note to Rule 34 adds an important gloss: data that is searchable in ordinary use generally should not be produced in a form that removes or significantly degrades that feature. Many states have adopted similar rules, but wording and defaults vary, so check the rules and any standing ESI orders in your court.

PDF, TIFF with load files, or native: how do they compare?

Each format trades usability for fidelity in a different way. Many productions end up as a hybrid.

Format	What the receiver gets	Strengths	Weak spots
Image-only PDF	Page images with no text layer	Easy to read and print; Bates on every page	Not searchable; metadata gone; degrades searchable originals
Searchable PDF	Page images with a text layer, Bates-stamped	Familiar, searchable, no review platform needed	Metadata only if provided separately; spreadsheets and media render poorly
TIFF, text and load files	Single-page images, text files and a metadata file	Loads into review platforms with fields intact	Needs a platform to use; more to generate and check
Native	Original files with a Bates placeholder and hash	Full fidelity: formulas, hidden content, embedded metadata	No page-level Bates; easier to alter; harder to redact

What is actually inside a load file production?

A load file production is a folder structure plus two index files that let review software rebuild every document with its fields. A typical volume contains:

Images: page images named by Bates number
Text: one extracted or OCR text file per document
Natives: files produced natively, named by Bates number
Data: a delimited metadata file (commonly a .DAT) and an image cross-reference file (commonly .OPT or .LFP)

Commonly requested fields include BegBates, EndBates, BegAttach, EndAttach, Custodian, From, To, CC, BCC, Subject, DateSent, FileName, FileExtension, DateCreated, DateModified, a hash value, and paths to the native and text files. A natively produced item is represented in the image set by a slip sheet, a single Bates-numbered placeholder page, so the numbering stays continuous.

Which format fits which kind of data?

Match the format to what makes the data meaningful. A single format applied to everything is a frequent source of re-productions.

Data type	Commonly sensible format	Why
Email and attachments	Searchable PDF or TIFF with load files, plus header fields	Header data and family relationships matter
Spreadsheets	Native with placeholder	Formulas and hidden rows or columns
Audio and video	Native	Cannot be imaged
Photos	Native, plus an exhibit PDF	Capture metadata; see photo metadata for litigation
Documents with tracked changes	Native, or images that show markup	Imaging can hide revisions and comments
Text and chat messages	Paginated PDF log plus the structured export	Thread context and field-level data
Databases and app data	Agreed report or export	No single “document” exists

How redactions change the picture

Redaction is where format plans often break. A native file cannot carry a visible, burned-in redaction the way an image can, so redacted documents are commonly produced as images or PDFs, with the text layer regenerated after redaction so the hidden words are not still searchable underneath. Redacted spreadsheets may need a redacted native copy or an agreed alternative. Check that metadata fields for redacted documents, such as an email subject line, do not reveal what the redaction protects, and list privilege redactions on the log.

How should text messages and chats be produced?

Chats do not fit document-centric formats, so the usual answer is to unitize them and pair a readable rendering with the structured data. Decide the unit first: a whole thread, a thread per day, or a thread per week or month. Then produce a chronological, Bates-numbered rendering that shows the sender, recipients, date and time with time zone, and channel for each message, with attachments cross-referenced, alongside the export file it came from and a hash of each source file.

Message Extractor, for example, generates that readable layer: a chronological, paginated PDF log with Bates-style numbering, an automated index, an attachment appendix and a SHA-256 digest. If a protocol calls for load files, those come from a review platform or vendor. Our workflow for producing text messages in discovery covers collection and review in detail.

Sample format language for requests and ESI protocols

Short, data-type-specific language prevents most disputes. Adapt this to the tools both sides actually use:

Sample wording

(1) Documents other than those listed below shall be produced as searchable PDF files, one file per document, Bates-numbered on each page, with parent and attachment relationships preserved by consecutive numbering.

(2) Spreadsheets, audio, video and files that cannot be rendered legibly as images shall be produced natively, named by Bates number, with a Bates-numbered placeholder page in the PDF set.

(3) Text and chat messages shall be produced as a chronological, Bates-numbered PDF log by thread showing date, time with time zone, sender and recipients, with attachments cross-referenced, together with the export file from which the log was generated.

(4) The producing party shall provide a delimited index listing, for each document, BegBates, EndBates, custodian, date, author or sender, recipients, file name and hash value.

(5) Either party may request native production of specific documents for good cause, and the parties will confer on any such request.

Item 4 delivers most of the metadata value of a load file production without requiring either side to run a review platform. Raise these terms at the ESI meet-and-confer, before anyone collects.

Questions to settle before you agree

What review tools does each side actually use, and can they read load files?
Which metadata fields matter to the issues, by name?
How will spreadsheets, media and messages be handled?
How will redacted documents be produced, and how will their text layers be rebuilt?
What Bates prefix, numbering and volume naming will each side use?
Which time zone will date fields and renderings use?

What mistakes force a re-production?

Many of them come from converting data in a way that loses something the other side was entitled to.

Printing to paper and scanning, which strips the text layer and all metadata
Flattening spreadsheets to PDF, which hides formulas and columns and can explode page counts
Collecting files by casual copying, which can change file-system dates
Inconsistent Bates prefixes or gaps between volumes; see the Bates numbering guide
Natives produced without placeholders or hash values
Promising metadata fields your tools cannot generate
Date fields delivered without a stated time zone

Format choices interact with privilege, cost and strategy, so the final call belongs to the attorney on the matter, and state courts may set different defaults. Confirm local requirements with counsel licensed in the jurisdiction before committing to a protocol.

Frequently asked questions

What is a DAT file in discovery?

A DAT file is a delimited text file that carries metadata for each produced document, such as beginning and ending Bates numbers, custodian, dates, sender, recipients and file paths to the images, text and natives. Review platforms read it to rebuild each document with its fields. It is one of the load files in a TIFF-plus-load-file production, usually paired with an image cross-reference file.

Is a PDF production a reasonably usable form?

Often, for documents, especially when the PDFs are searchable, Bates-numbered and organized so family relationships are clear. It is weaker for email when header metadata matters and poor for spreadsheets, audio and video. Producing image-only PDFs of data that was searchable in ordinary use may draw an objection, because the advisory committee notes to Rule 34 caution against degrading searchability.

Can the other side demand native files?

A requesting party may specify native format under Rule 34(b)(1)(C). The responding party can object and state the form it intends to use, and disagreements are resolved by agreement or by the court. Many protocols settle on PDF or image production for most documents, natives for spreadsheets and media, and a process for requesting specific natives for good cause.

Do you have to produce metadata in discovery?

Not automatically. Whether metadata must be produced depends on the request, the parties’ agreement, any court order and whether the data is relevant and proportional. Native files carry their embedded metadata, while image or PDF productions include only the fields delivered separately in a load file or index. Agreeing on a short, named list of fields avoids most disputes.

Who pays to convert documents into the requested format?

Generally, the producing party bears the cost of producing its own data in the agreed or ordered form. If a requested form would impose undue burden or expense, the producing party can object, propose an alternative, or seek a protective order under Rule 26(c), which can allocate expenses. State rules and local practice vary, so cost questions are best raised at the planning conference.