An eDiscovery load file is a text-based index that tells review software how to reassemble a document production from its component parts. It maps metadata, extracted text, and page images to every document in a dataset so a legal team can search, sort, and review electronic evidence without manually reconnecting thousands of files. Get the load file wrong and reviewers open the production to orphaned images, unsearchable text, or metadata attached to the wrong records.
What a Load File Does in a Production
When one side produces thousands of emails and attachments to the other, the delivery does not arrive as a single neat package. The metadata (who sent it, when, to whom) sits in one place. The page images sit in a folder of TIFF or PDF files. The searchable text sits in yet another set of files. The load file is the instruction sheet that tells the receiving platform which metadata row belongs to which image, and where to find the corresponding text file for each page.
Without it, importing a production would be like receiving a disassembled bookshelf with no instructions. The load file supplies the document identifier for each record, the file paths pointing to its images or native files, and the column-by-column metadata that makes the document searchable and sortable inside the review tool.
The Two Files You’ll Usually Receive
Most productions involve two load files working together, each handling a different job. Confusing the two is one of the more common mistakes when encountering a production for the first time.
Concordance DAT (Metadata)
A metadata load file is almost always a Concordance DAT file: a flat text file where each row represents one document and each column represents a metadata field. Typical fields include the beginning and ending Bates numbers, custodian name, date sent, sender, recipients, subject line, file type, and the path to the native file or extracted text. The DAT format uses distinctive delimiter characters that differ from ordinary commas or tabs. The default field separator is the character at ASCII position 20 (¶), and text fields are wrapped in the character at ASCII position 254 (þ).1CloudNine Answer Center. Managing Data Files – Concordance Those unusual delimiters exist for a practical reason: they almost never appear inside actual document text, so the software can reliably tell where one field ends and the next begins.
Opticon OPT (Images)
An image load file is typically an Opticon OPT file, and it handles a different task. Each line represents one page and contains the page identifier (its Bates number), the file path to that page’s image, and a marker indicating whether that page is the first page of a new document.2Relativity. IE Load File Specifications – RelativityOne That “Y” marker on the first page is what tells the platform where one document ends and the next one begins. Without it, every page would be treated as a separate, unrelated file.
The two files link through the Bates number: the beginning Bates in each DAT row matches the first page identifier flagged with “Y” in the OPT file.
What’s Inside
Regardless of format, a load file delivers three categories of information the review platform needs.
Metadata
Metadata describes the document rather than its content. For an email that means the sender, recipients (To, CC, BCC), date sent, subject line, and attachment names. For a loose file like a Word document or spreadsheet, it includes the author, creation date, last modified date, and file size.3Microsoft Learn. Document Metadata Fields in eDiscovery Metadata is what lets reviewers filter by date range, sort by custodian, or isolate every email from a particular sender. Those tasks are impossible if the platform only has page images.
Which fields appear in a given load file depends on what the parties negotiate. Some productions also include hash values, which are digital fingerprints generated by running each file through an algorithm. Hashes let the receiving party verify that files were not altered in transit and identify duplicates across custodians.
Extracted Text
Extracted text is the readable content pulled from each document. For an email, it is the body text. For a Word file, it is the full text. The content is typically stored in individual text files, one per document, that the load file points to by file path. Extracted text is what powers full-text searching inside the review platform. A reviewer searching for the word “merger” against TIFF images alone would get zero results, because images are pictures of pages and pictures are not searchable.
For documents that were originally paper and then scanned, the text comes from optical character recognition rather than direct extraction, and it tends to be less reliable.
Image and Native File Pointers
A load file does not contain the actual documents. It contains file paths, which are directions telling the platform where to find each image, native file, or text file on disk. This is where things break most often. If the folder structure on the receiving end does not match the paths in the load file, the platform cannot locate the images and the import fails. A path like \IMAGES\001\DOC00001.TIF only works if that exact structure exists relative to where the load file sits.
Productions typically include image renditions with Bates stamps for consistent page-by-page review, and sometimes native files for document types that do not convert well to images. Spreadsheets are the classic example, since a flattened image of an Excel file loses formulas, hidden tabs, and the ability to scroll through columns.
Standard Load File Formats
Three formats dominate the industry. Most review platforms can ingest all three, though practitioners encounter the first two far more often than the third.
- Concordance DAT is the most common metadata load file format. It is a delimited text file using non-standard ASCII characters as separators to avoid conflicts with the commas and quotes that naturally appear in document text. Each row is one document; each column is one metadata field.
- Opticon OPT is the standard image load file format. Each line represents a single page image, with comma-separated fields for the page identifier, volume label, image file path, document break marker, and page count. It works alongside the DAT.2Relativity. IE Load File Specifications – RelativityOne
- EDRM XML is an open standard maintained by the Electronic Discovery Reference Model organization. It bundles metadata, file paths, and document relationships into one self-describing XML file, eliminating the guesswork around delimiters and field mapping that can trip up DAT imports. Adoption has grown, but DAT and OPT remain the default pairing in most productions.4EDRM. EDRM XML White Paper
Native Productions vs. Image Productions
The load file’s role shifts with the production format.
In an image-based production, every document is converted to TIFF or PDF page images with Bates stamps. The load file is essential here, because it is the only thing linking those images back to their metadata and searchable text. Image productions remain common because Bates-stamped pages are easy to reference in depositions and briefs, and the format prevents accidental modification of the original file.
In a native production, documents arrive in their original file format: Word files stay as .docx, spreadsheets as .xlsx. The load file still accompanies the production, but its job is narrower. It provides the fielded metadata and the mapping between each native file and its document identifier. Native files preserve functionality that images destroy, including spreadsheet formulas, embedded links, and PowerPoint animations. The tradeoff is that native files can be modified when opened and cannot carry traditional Bates stamps on their pages.
Many productions use a hybrid approach. Most documents go out as Bates-stamped images with a full load file, while spreadsheets, audio files, and other format-sensitive documents are produced natively.
Why Load Files Carry Legal Weight
Load files are not just a technical convenience. They are how parties satisfy their legal obligations when producing electronic evidence. Federal Rule of Civil Procedure 34 requires that when a requesting party does not specify a production format, the producing party must deliver electronically stored information either in the form it is ordinarily kept or in a “reasonably usable form.”5Legal Information Institute. Federal Rules of Civil Procedure Rule 34 – Producing Documents, Electronically Stored Information, and Tangible Things, or Entering onto Land, for Inspection and Other Purposes A pile of TIFF images with no load file is not reasonably usable. The receiving party would have no metadata, no searchable text, and no way to tell which pages belong together.
This is why production format negotiations matter at the start of a case. Parties typically agree during their Rule 26(f) conference on which metadata fields the load file will include, whether documents will be produced as TIFFs with a load file or in native format, and which load file format to use.6Legal Information Institute. Federal Rules of Civil Procedure Rule 26 – Duty to Disclose; General Provisions Governing Discovery Nailing down these details early prevents the costly disputes that erupt when one side produces a dataset the other cannot load.
Where Load Files Break
Load file errors are frustrating because they are often invisible until you try to import, by which point you may have spent hours downloading and organizing the delivery.
- Broken image paths. The most common failure. The file paths in the OPT or DAT do not match the actual folder structure on disk. Relative paths starting from the load file’s location are more portable than absolute paths starting from a drive letter.
- Delimiter mismatches. If the receiving platform expects standard Concordance delimiters but the load file uses different separator characters, fields get jumbled. A single misplaced or missing delimiter can cascade across the dataset, pushing metadata values into the wrong columns for hundreds of documents.
- Encoding problems. Load files containing non-English characters or special symbols can break during import if the file encoding does not match what the platform expects. UTF-8 is the current standard, but older productions sometimes use encodings that cause characters to display as garbled text.
- Missing text files. The load file references extracted text files that were not included in the delivery, or the file names do not match the identifiers in the load file. Documents appear in the platform but return no search hits.
- Document boundary errors. The “Y” markers in the OPT file are missing or misplaced, causing the platform to merge separate documents into one record or split a single document into multiple records.
Experienced litigation support staff validate a load file before importing. They check that the image paths resolve, that the field count is consistent across every row, and that the Bates ranges in the DAT match the page identifiers in the OPT. Catching these problems before import saves hours of troubleshooting inside the review platform.
Hash Values and Deduplication
Hash values are a less visible but important element that appears in many load files. A hash is a fixed-length string of characters generated by running a file through a mathematical algorithm; MD5 and SHA-1 are the most common in eDiscovery. Even a one-character change to the original file produces a completely different hash. That makes hashes useful for two things: verifying that files were not altered in transfer, and identifying duplicates across custodians.
Deduplication removes identical copies of the same document and relies on comparing hash values. If two emails collected from different custodians produce the same hash, the platform flags them as duplicates and the review team typically reviews only one. The dataset can shrink significantly as a result. The catch is that different platforms calculate hashes differently. Some hash only the extracted text, others hash the full binary file, and still others create a composite hash from the message body, recipients, and attachment names. Hashes generated in one platform often cannot be meaningfully compared to hashes from another, so deduplication works best when all documents are processed through the same tool.
Whether deduplication happens at the individual document level or at the family level (treating a parent email and its attachments as a single unit) is a workflow decision the legal team should make deliberately. Family-level deduplication is generally safer because it keeps parent-child relationships intact and avoids the scenario where an attachment drops out of review as a duplicate while the unique parent email it was attached to stays in.