Skip to main content
Records Authority
Category: E-Discovery and Legal Holds

Load File

Simply put

A load file is a structured text file that accompanies a set of documents or scanned images and tells e-discovery software how to import and organize them, including which pages belong to which document and what descriptive metadata attaches to each. It is often not a single file but several files that work together. Load files are commonly used when electronically stored information is exchanged during litigation, particularly in document productions.

Formal definition

In e-discovery, a load file is a structured, typically delimited text file (for example, a CSV or other delimited format) that maps documents, their pages or native files, and their associated metadata so that they can be imported into, exported from, or reviewed within a document review or database application. During import, the receiving application reads the load file to establish document boundaries and to populate metadata fields, cross-referencing the load file's entries against the corresponding image files, extracted text, or native files. Load files are most commonly encountered as part of document productions, especially image productions, where a set of processed or scanned files is delivered together with one or more load files that indicate where individual pages or documents begin and end and how the accompanying data relates to them. The exact format, required fields, and delimiters vary depending on the software involved and the specifications agreed between producing and receiving parties.

Why it matters

Load files are the practical mechanism by which structured document sets move between parties and systems during litigation. When electronically stored information (ESI) is exchanged in a document production, the documents themselves are only part of the delivery; the load file is what allows the receiving party's review software to reconstruct document boundaries and attach the correct descriptive metadata to each item. Without a correctly formed load file, a production of images or processed files may be difficult or impossible to import in a usable form, undermining the receiving party's ability to review and rely on the material.

Because the exact format, required fields, and delimiters vary depending on the software involved and the specifications agreed between producing and receiving parties, load files are a frequent point of negotiation and dispute in e-discovery. Disagreements over field mappings, delimiters, or which metadata fields must accompany a production can create delays and additional cost, and can compromise the integrity or usability of the transferred set if they are not resolved before delivery. Agreeing on load file specifications early, often as part of a broader production protocol, helps ensure that what one party produces can actually be ingested and organized by the other.

For records and information professionals, load files illustrate the difference between the underlying records or ESI and the accompanying structures needed to preserve their organization and context. The load file does not change the substance of the documents, but it carries the relational and descriptive information, document boundaries and associated metadata, that keeps a production coherent and reviewable. Handling load files carefully therefore supports the usability of records exchanged in litigation, though the specific legal obligations governing productions depend on the jurisdiction and the applicable procedural rules.

Who it's relevant to

E-discovery and litigation support specialists
These professionals prepare, validate, and ingest load files as part of document productions. They are typically responsible for ensuring that document boundaries and metadata fields map correctly during import and export, and for troubleshooting load files that do not conform to the expected specifications of a review or database application.
Litigators and legal teams
Attorneys and their teams rely on productions being importable and reviewable. Load file specifications, such as required metadata fields and delimiters, are often negotiated between producing and receiving parties, so understanding the role of the load file helps legal teams agree on workable production protocols and assess whether a production has been delivered in a usable form.
Records and information governance professionals
Those managing records and ESI benefit from understanding how load files preserve document organization and associated metadata when records are exchanged. This supports the usability of records in litigation contexts, while the specific procedural and disclosure obligations that apply depend on jurisdiction and sector.
Service and processing vendors
E-discovery service providers who process, scan, or convert ESI generate load files as part of their deliverables. They must accommodate the varying formats, fields, and delimiters required by different downstream review applications and by the specifications agreed for a given matter.

Inside Load File

Metadata fields
Structured data describing each document or record in the production set, such as document identifiers, dates, authors, recipients, and other coded fields used to load records into a review or storage platform. The specific fields depend on the agreed production or exchange specification.
Delimited data structure
A load file is typically a delimited text file (for example, using characters to separate fields and delimit values) that maps metadata and pointers to the associated content, allowing a receiving system to interpret and import the accompanying files.
Pointers to associated files
References or relative paths linking each entry to its corresponding native files, images, or extracted text, so that the content can be located and rendered by the importing application.
Document relationships
Information that often preserves family or grouping relationships, such as parent-child links between an email and its attachments, and beginning and ending boundaries that define where one document ends and the next begins.
Format conventions
The particular layout, field order, delimiters, and encoding a load file uses generally follow a named specification agreed between the parties, and different platforms or productions may expect different conventions.

Common questions

Answers to the questions practitioners most commonly ask about Load File.

Is a load file the same as the documents or records it accompanies?
No. A load file is a structured file, typically delimited text, that describes and points to a set of documents or records so that a receiving system can import them correctly. It is not the content itself but the accompanying map of metadata, field values, and file paths. Confusing the load file with the underlying records can lead to errors during loading, since the load file may reference material that is missing, misnamed, or inconsistently structured. Depending on the tools and workflow involved, the load file works alongside the exported content rather than replacing it.
Does a load file guarantee that the imported material qualifies as an authoritative record?
Not on its own. A load file governs how data and documents are transferred into a system, but it does not by itself establish the authenticity, reliability, integrity, or usability that distinguish an authoritative record from a copy or transitory information. Whether the loaded material retains its evidential value depends on how the export and import were controlled, what metadata was preserved, and the recordkeeping practices of the receiving environment. A load file supports the transfer process; it does not confer record status.
What information does a load file typically contain?
A load file typically contains structured fields that identify each item and its associated metadata, along with references or paths to the corresponding document files. Common elements often include identifiers, field values used for classification or review, and pointers to the location of native, image, or text content. The exact fields depend on the format chosen and the requirements of the receiving system, so practitioners generally confirm the expected schema before generating or importing a load file.
How should delimiters and encoding be handled when preparing a load file?
Because a load file is usually a delimited text file, the choice of delimiters, text qualifiers, and character encoding often determines whether it loads cleanly. Values that themselves contain the delimiter character can corrupt the field structure if not properly qualified. Practitioners typically agree on these conventions in advance and validate a sample before processing the full set, since a mismatch between the file's actual encoding and the settings expected by the receiving system can cause import failures or misaligned data.
What validation steps are advisable before importing a load file?
Validation commonly includes confirming that the field structure matches the receiving system's expected schema, checking that referenced file paths resolve to existing content, and verifying that record counts and key identifiers are consistent between the load file and the accompanying material. Testing with a small subset before a full load can help surface problems early. The specific checks depend on the tools in use and organizational policy, and a documented validation step supports later confidence in the completeness of the transfer.
How can errors or mismatches in a load file be addressed during implementation?
When a load file fails to import or produces mismatches, practitioners often review error logs, isolate the affected records, and correct the underlying field, path, or encoding issue before reattempting the load. Depending on the workflow, it may be preferable to regenerate the load file from source rather than edit it manually, since manual edits can introduce further inconsistencies. Keeping a record of what was corrected supports traceability, particularly where the loaded material is intended to serve as evidence of activity.

Common misconceptions

A load file is itself the record or the content being exchanged.
A load file is generally a structured index or map that describes and points to the accompanying content and metadata; it is not the substantive record. The authoritative record content typically resides in the associated native files, images, or extracted text that the load file references.
There is a single universal load file format that all systems accept.
Load file conventions vary. Different platforms and productions may expect different field orders, delimiters, encodings, and structures, so a load file prepared for one specification will not necessarily import correctly into another system without mapping or transformation.
A valid load file guarantees the completeness and integrity of the underlying records.
A well-formed load file supports usability by enabling import, but it does not by itself establish the authenticity, reliability, or integrity of the referenced records. Those properties depend on how the records were created, captured, and maintained, and typically require separate verification such as confirming that referenced files are present and correctly linked.

Best practices

Agree on and document the load file specification (field list, field order, delimiters, encoding, and file references) with the receiving or exchanging party before generating the file, since conventions differ across platforms.
Validate that every pointer in the load file resolves to an existing associated file, and reconcile counts between the load file entries and the delivered content to detect missing or orphaned items.
Preserve document relationships explicitly, such as parent-child links and document boundaries, so that email-attachment families and multi-page documents import intact.
Confirm consistent delimiters and character encoding, and test-import a representative sample into the target system to surface parsing or mapping errors before the full load.
Retain a record of the specification used and of the load and validation results, so the exchange can be traced and any discrepancies investigated later.
Treat the load file as an index that supports usability rather than as evidence of record integrity, and verify authenticity and completeness of the underlying records through separate, appropriate controls.