Know what's in the volume before your platform does.
Drop the load files from a production. Read what they actually say — the dialect, the Bates account, whether the four files agree. Nothing you drop leaves this browser.
Replay — VOL00001, a real 3,158-document federal production
0documents read
BATES CONTINUITY EFTA00000001 → EFTA00003158
⚠ simulated finding — 4 numbers missing between EFTA00001042 and EFTA00001047, reported with sizes and line numbers
All four files describe the same 3,158 documents — no cross-file findings
That volume is in the public record, and in our test suite. Yours runs the same way — in this tab, on your machine.
Run yours
Up to four files from one volume. The reports appear right here.
Every report is free, on every volume. Exports are capped at 3 a day — $39 once removes the cap on this machine. No account, no subscription.
Every bad volume tells the same story
01
The import fails. Or worse, it doesn't.
A malformed row stops the load at line 847 — or the volume imports cleanly and two documents are quietly merged. The second one costs more. You find out in review.
02
The file tells you nothing.
No version header, no schema, no declared encoding. In a text editor it's line noise. The one question that matters — what did they actually send — has no viewer.
03
So you read it here first.
Drop the volume before it goes anywhere near your platform. The dialect, the Bates account, and a cross-file agreement check, in seconds. Import with the answer in hand.
01 — The checks
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:
Invented example — a Bates continuity finding
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.
Convert DAT to CSV — and back to standard
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.
02 — The field guide
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. None of them is self-describing: no version header, no schema, no declared character encoding — a file is correct only 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 four dossiers below are written from the files we test against, with invented Bates numbers.
"Nothing uploads" is not a slogan here; it is a property you can test in under a minute, on this page, today.
Load this page. Let it finish. That is the last network request it needs.
Go offline. Airplane mode, or pull the cable.
Drop a volume. Detection, validation, cross-checks and both exports all still work. A tool that was sending your files somewhere could not do that.
Prefer to watch instead: open your browser's network panel and drop a file. The only requests on this page are its own files — same origin, no third-party hosts, no analytics, no telemetry, no session recording. The fonts are served from this domain for exactly that reason.
Free, forever
Every report. Every volume.
Detection, validation, Bates continuity, cross-file checks, full preview. No account. Exports capped at 3 a day.
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.
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.
Built against a 44-file corpus of real and sample load files, 39 of which run in the automated test suite on every change. It holds a real 3,158-document production volume, files from three open-source projects, and files we broke on purpose — mixed encodings, mismatched volumes — alongside damage written directly into the tests: a text qualifier opened and never closed, and Bates padding that drifts mid-volume. The five it does not exercise are bonus fixtures in a format this tool does not claim to read.