eDiscovery Load File Converter & Validator — DAT, OPT, LFP, DII

01

What's in a load file

A production arrives as a folder of images or native files plus two to four small text files that tell a review platform how to reassemble them. Those text files are the load files. Each one is plain, line-oriented text, and each answers a different question: the DAT carries the metadata table, the OPT or LFP says which image file is which page of which document, and the DII does the image-and-fields job in a token grammar of its own.

None of them is self-describing. There is no version header, no schema, no declared character encoding — the file is correct if the platform loading it happens to make the same assumptions the tool that wrote it made. That is why most load-file trouble is silent: the volume imports without complaint and the damage shows up in review, weeks later. The four explainers below are written from the files we test against, with invented Bates numbers.

DAT — the metadata table

A DAT is a delimited table: one header line naming the columns, then one line per document. If a vendor hands you a Concordance DAT load file, this is what is inside it — custodian, dates, file names, subject lines, the Bates range each document occupies, and whatever else the producing party agreed to give you.

What it is not is a CSV. Real document metadata contains commas constantly (Rivera, Dana), quotation marks inside subject lines, tabs pasted in from spreadsheets, and line breaks inside comment and body fields. Every ordinary delimiter is already in the data. So the convention went the other way: delimit with characters that a business record will never contain. The usual set is ASCII 20 between columns, thorn (þ, ASCII 254) wrapped around every value, and the registered sign (®, ASCII 174) standing in for a line break that occurred inside a value. This is the pairing Concordance-style exports use by default, and it is what most platforms expect when someone asks you for "a DAT".

þBegBatesþ␔þEndBatesþ␔þCustodianþ␔þCommentsþ
þACME0000001þ␔þACME0000004þ␔þRivera, Danaþ␔þProduced 2026-03-11.®Redacted per privilege log entry 44.þ
þACME0000005þ␔þACME0000005þ␔þChen, Marcusþ␔þþ

þ

Text qualifier. Wraps every value, including empty ones — that is why the last field of the second row reads þþ. Because values are wrapped, a value may contain the column separator without breaking the row.

␔

Column separator, ASCII 20. It is a control character with no glyph of its own, so it is invisible in a text editor; we print it as ␔ here and in the tool so you can see where it sits — directly between the closing þ of one value and the opening þ of the next, with no space.

®

A line break that was inside a value. One document is one physical line, so a two-paragraph comment is stored with its newlines swapped for this character and restored on import. One thing to know before you export: we pass this character straight through into the CSV rather than turning it back into a line break, so a value that used it arrives in your spreadsheet with the ® still in it.

The cost of choosing unprintable delimiters is that the file looks like line noise in Notepad, Excel will not open it usefully, and a well-meaning edit in the wrong editor can destroy it. The benefit is that no value ever has to be escaped, which is the failure mode CSV never fully solved.

Not every producer ships that set, so we detect the dialect instead of assuming it. The tool samples the first 40 lines, tries each known delimiter/qualifier pairing, and keeps the one that yields a consistent column count across those lines — then tells you which one it found rather than quietly proceeding. Five families turn up in our corpus, and all five are covered by tests against files in it: ASCII 20 with þ; the inverted convention with þ between columns and ® as the qualifier; pipe with a caret qualifier; pipe with double quotes and CSV-style doubled-quote escaping; and tab-delimited with no qualifier at all. Header names vary as much as delimiters do — BegBates, BEGDOC, ProdBeg, Control Number and a dozen more — so the Bates columns are matched by normalized name rather than by position.

OPT — one line per page

An OPT is the image cross-reference: seven comma-separated fields per line, one line per page rather than per document. It is commonly called an Opticon file, after the image viewer whose convention it follows. In order, the fields are the image key (the Bates number of that page), the volume label, the path to that page's image file, the document-break flag, two fields that are reserved and in practice always empty, and the page count.

The document-break flag is the load-bearing one. It holds Y on the first page of each document and is empty on every continuation page; nothing else in the file says where one document ends and the next begins. The page count appears on the break line and describes the whole document. So a three-page document is three lines with Y on the first only:

ACME0000001,VOL001,IMAGES\001\ACME0000001.tif,Y,,,3
ACME0000002,VOL001,IMAGES\001\ACME0000002.tif,,,,
ACME0000003,VOL001,IMAGES\001\ACME0000003.tif,,,,

A dropped Y silently merges two documents; a stray one silently splits one in half. Neither stops the volume importing. The validator flags both shapes it can see from the file alone: a continuation row that appears before any document break at all, and a declared page count that disagrees with the number of rows that actually follow.

LFP — the same job, command-oriented

LFP is the image load file of the IPRO lineage. It carries the same information as an OPT, but each line begins with a two-letter command rather than being purely positional, and image records share the file with other record types — offline or native-file records, replacement records, issue records. We read the IM image records and keep the rest aside verbatim, reporting what was there rather than discarding it or refusing the file.

An IM record is: the command, the page key, a boundary flag, an offset, and then an @-block that locates the file. The boundary flag is the document structure — D opens a document, C opens a child document (an attachment), and blank or a single space means "another page of the document already open". The @-block is semicolon-separated as @Volume;Directory;File;Type, where the type is a small numeric code for the image kind — 2 for TIFF and 5 for PDF in the volumes we have seen.

IM,ACME0000001,D,0,@VOL001;IMAGES\001;ACME0000001.tif;2,
IM,ACME0000002, ,0,@VOL001;IMAGES\001;ACME0000002.tif;2,
IM,ACME0000003, ,0,@VOL001;IMAGES\001;ACME0000003.tif;2,

There is an older shape in circulation where the path sits inline with a page number instead of a semicolon block, which puts the boundary flag in a different field position. Guessing per line would misread half a file, so the tool decides from the first image record which shape the file uses and stays with it for the rest of the file.

DII — a token on every line

DII comes from the Summation lineage and abandons columns entirely. Every line is either a token beginning with @ or a bare continuation line, and a record ends where the next one starts — there is no terminator to leave off. @T opens a document and carries its ID. @C NAME value sets one named metadata field, one field per line. @D gives the image directory, and the bare lines that follow it are that document's page files, in page order. Lines beginning with a semicolon are comments, and any @-token appearing before the first @T is a file-level directive rather than part of a record.

@T ACME0000001
@C PGCOUNT 3
@C CUSTODIAN Rivera, Dana
@D @I\IMAGES\001\
ACME0000001.tif
ACME0000002.tif
ACME0000003.tif

The @I\ prefix on the directory is a placeholder that the loading platform substitutes with the volume root, which is why a DII can be moved between machines without rewriting every path. One trap worth knowing: a second, unrelated grammar also ships with the .dii extension, in which a bare @D opens a record, @T names a field whose value runs over as many lines as it needs until a bare @E closes it, and @EDOC closes the record. Same extension, different language. We identify which one a file speaks before parsing a single record, and handle both.

02

What the validator checks

Three passes, in this order: within the Bates numbers, between the files, and inside each row. Everything is reported, nothing is repaired — a QC tool that silently fixes your production is worse than no tool.

Bates continuity

The Bates columns are found by header name, tolerating the usual spelling variations, and used as a begin/end pair where both exist or as a single column where they do not. Each value is split into a prefix and its trailing digits, and the values are walked in file order. In range mode the comparison that matters is the next document's begin against the previous document's end, which is what makes a genuine gap distinguishable from an ordinary multi-page document.

Four findings come out of that walk. Gaps — numbers missing between one document and the next. Duplicates — the same Bates value claimed twice, which is checked at both ends of every range, because a page is just as double-claimed when it reappears as somebody's END as when it reappears as a BEGIN. Out of order — a value that does not advance on the one before it. Padding drift — the digit width changing mid-prefix, as in ACME000045 arriving after ACME0000044, which is rarely how software numbers a volume and usually means a value was typed by hand.

A change of prefix is treated as the start of a new segment rather than as a gap, because concatenating volumes from several sources is normal and flagging it would bury the real findings. Each segment is reported with its own first value, last value and document count. A gap is a warning, never an error: documents pulled for privilege after numbering leave exactly this trace, so the finding is the beginning of a comparison against the privilege log, not a verdict. What the report looks like:

Prefix   First         Last          Count
ACME     ACME0000001   ACME0000902   417

Gaps
  10 missing between ACME0000120 and ACME0000131
  1 missing between ACME0000488 and ACME0000490

Read that as: 417 documents spanning ACME0000001 to ACME0000902, with eleven numbers unaccounted for in two places. If the privilege log claims ten withheld documents in the first range, the second gap — a single number — is the one to ask about.

Cross-file agreement

Load two or more of a volume's files together and they get checked against each other, which catches the class of error that no single file reveals. Document counts from each file are put side by side: DAT rows, OPT document breaks, LFP document and child records, DII records. When they disagree, at least one of the files is describing a different set of documents than the others — often a volume that was regenerated after one file had already been written.

Membership is then checked in both directions between the DAT and the OPT: DAT documents with no matching document break in the OPT, and OPT documents with no matching row in the DAT. Finally, every OPT continuation page is tested against the set of begin-to-end ranges declared in the DAT. A page whose number falls outside every declared range is either an image that does not belong in the volume or a DAT range that is wrong, and both are worth knowing before the volume goes out.

Per-row structural issues

The parsers never throw. A malformed row is marked and parsing continues, so you get a report on the whole file instead of an error message about line 12. Findings are grouped by kind with the first line numbers they occurred on, so a systematic problem reads as one finding with 3,000 lines rather than 3,000 findings.

In a DAT, that means rows whose field count does not match the header, values left unwrapped where the rest of the file wraps them, a text qualifier opened and never closed (which swallows everything after it), and the whole-file convention of a trailing delimiter on every line. In an OPT: fewer than seven fields, an empty image key or path, a break marker that is something other than Y, and a page count that is not a positive integer or that disagrees with the rows following it. In an LFP: an image record with no @-block, an unrecognized boundary flag, a non-numeric offset, a short path block. In a DII: content before the first record, a field left open at end of file, a record not closed before the next one opens. Character encoding is checked first, on every file — byte-order marks are honored, UTF-8 is verified rather than assumed, and a file that is not valid UTF-8 is read as Windows-1252 and labeled as such, because that is what an unlabeled load file from a Windows tool almost always is.

03

Convert DAT to CSV

The CSV export is the one people come for: a DAT that Excel refuses to open, turned into a file it opens by double-click. It is written to RFC 4180 — comma-separated, CRLF line endings, values quoted only when they contain a comma, a double quote or a line break, and embedded quotes doubled. It begins with a UTF-8 byte-order mark, which is what stops Excel guessing a local code page and mangling every accented custodian name in the volume. Multiline values survive: a comment field that held a line break in the source keeps it, quoted, so it stays in one cell instead of spilling into the rows underneath. The header row is written exactly as it was read — no renaming, no reordering, no dropped columns.

The standard-DAT export goes the other way, and exists for the case where you were sent a load file in one of the odd dialects and need to hand on something ordinary. Whatever came in — pipe and caret, pipe and quote, tab, the inverted thorn convention — goes out in the default set: ASCII 20 between columns, þ around every value, ® for newlines inside a value, UTF-8 with a byte-order mark, CRLF line endings. That is the shape most platforms import without a custom profile, so it is what to send when someone asks for a Relativity-ready load file. One honest caveat, because it is a real limitation and not a rounding error: the thorn qualifier has no escape sequence, so if a source value literally contains a þ, we remove that one character and tell you how many rows were affected. The alternative would be writing a file that misparses on import without saying anything.

04

Questions we would ask

Is it really free?

Validation and preview are free and unlimited: drop as many volumes as you like, read every detection, validation and cross-file report, and look at the parsed table. Exports are capped at 3 per day. Each download click counts as one export, so exporting the same file as CSV and as DAT uses two. $39 once removes that cap on that machine, permanently — one payment, no account, no subscription, nothing to cancel. The daily count lives in your browser's local storage and resets at midnight, local time.

Does anything upload?

No. There is no server to upload to: the page is static files, and the parsing runs in your browser tab. Do not take our word for it — the claim is designed to be checked. Load this page, disconnect from the network (airplane mode, or pull the cable), and then drop a volume in. Detection, validation, cross-checks and both exports all still work. A tool that was sending your production somewhere could not do that. If you would rather watch than test, open your browser's network panel and drop a file: there are no requests. There is also no analytics, no telemetry and no session recording on this page.

Which formats does it handle?

In: DAT in any of the dialects described above, OPT, LFP in both path shapes, and DII in both grammars. Out: CSV, and standard-delimited DAT. Load-file formats that are themselves CSV — the kind some cloud e-discovery exports produce — are not supported yet. We have never had a real sample of one to build against, and we would rather say so than guess at a format we have not seen fail. Send us a failing file and we'll add it.

Will my review platform accept the output?

The DAT export uses the delimiter set platforms import without a custom profile, and the CSV is standard RFC 4180, so in the ordinary case yes. We cannot promise it for every platform and every import profile, and we are not in a position to: this is an independent, unofficial tool with no affiliation to, endorsement from, or certification by any e-discovery software vendor. Load a small test volume before you send a production out on the strength of it — which is good practice regardless of what wrote the file.

What about very large files?

Everything is parsed in memory, in one browser tab, and that is the honest limit of the design. The DAT parser walks the file character by character rather than splitting on newlines, because a qualified value can itself contain a newline and records cannot be found by line — fast, but not free. A few tens of megabytes is comfortable. Several hundred will be slow, and on a low-memory machine a very large volume can fail outright. The preview table deliberately renders only the first 200 rows; the export always writes every row. If you hit the ceiling, split the volume by custodian and run the parts.

Something is wrong, or my file is not recognized.

Email support@nothinguploads.com, and attach the file if you can share it — a redacted or synthetic sample that reproduces the problem is just as useful. Format edge cases are the entire job here, and a file that fails is the most useful thing anyone can send us.