The Epstein Files, Forensically

Executive Summary

This is an independent study, conducted entirely with our own forensic engine. We ran every PDF in the DOJ "Epstein Files Transparency Act" disclosure — all 16,971 documents, all 47 engines, zero files skipped or failed — and report what the scanner found at the object level.

The corpus is clean of malware. That is the expected, correct result for a government document production, and it is not the story. The story is provenance — what these files are, how they were made, and what they carry that a human reader never sees:

• Two distinct production pipelines partition the entire release, visible in the bytes (PDF 1.3 + compressed object streams + three EOF markers vs PDF 1.5 + two).
• A dated production timeline — the documents were processed in distinct waves between December 2025 and February 2026, with a single 6,583-document batch on one day.
• The corpus underwent a digital-to-image transformation workflow before release — OCR-captured, rasterized, re-saved — with image and structural characteristics far more uniform than native scanner output.
• 96.7% carry data the renderer never shows: invisible text layers, OCR text that diverges from the image, hidden compressed objects, orphaned objects — including the original metadata the active document appears to have erased.
• 18.6% present different content to a human than to a machine, and 61.9% make PDF parsers disagree about the document's own structure.

The release is safe to open. Its risk is to interpretation. Note the deliberate limit of these findings: structure can show that a digital-to-image transformation occurred; it cannot, by itself, establish whether the underlying content was altered. We report the observable technical facts and stop there.

Finding 1 — Two Distinct Production Pipelines

Two assembly pipelines produced the release — a 10,718-document population (header 1.3, with compressed object streams) and a 5,828-document population (header 1.5) — cleanly separable from the bytes alone.

The release was not produced by a single process. The header PDF version partitions the corpus into two tightly-correlated populations, and the correlation is near-total:

Pipeline A's documents claim PDF 1.3 in their header but use 1.5-era object streams internally — the inconsistency that makes parsers disagree (Finding 6). Both populations share the same OCR toolchain (Finding 4); the split reflects two assembly passes or source batches, cleanly separable from the bytes alone.

Finding 3 — A Dated Production Timeline

Surviving timestamps cluster into dated processing waves from December 2025 to February 2026 — batch production, not a single export — while 14 files retain an original 2013 creation date.

The revision metadata that survived processing carries timestamps, and they cluster into distinct dated processing waves — not a single export. Of the ~10,947 documents whose dates are readable, the production ran from December 2025 into February 2026, dominated by one 6,583-document batch:

Two observations follow. First, the production is batch-processed in waves, consistent with the two-pipeline split in Finding 1. Second, 14 documents retain a pre-2025 original creation date (2013-04-16) — and the recovered metadata names them as Microsoft® Office Word 2007 documents (Finding 4): genuine born-digital originals whose provenance survived the transformation in the orphaned metadata, a reminder that the underlying documents predate this release by years.

Finding 4 — Metadata Stripped From View, but the Toolchain Is Recoverable

Active authoring metadata is 100% empty, but the orphaned /Info dictionary recovers the production toolchain on 65.8% of files — resolving the corpus into four generators that match the structural pipelines exactly.

All 16,971 documents (100%) have empty Producer, Creator, Title and Author fields in their active metadata, and none carry XMP. The strip is total, not near-total: not one document in the corpus retains a populated Title, Author, Subject, Keywords or Trapped value. On the surface the authoring fingerprints look erased.

They were not erased — only unlinked. The pipeline left the original /Info dictionary behind as an orphaned object inside a compressed object stream, unreferenced by the final trailer. Walking every cross-reference object recovers it. Measured across the full corpus, 11,165 documents (65.8%) still carry a recoverable authoring fingerprint in that orphaned metadata — every one of them with an empty active /Info. The recovered values do not describe one pipeline; they resolve the corpus into four distinct generators, and each one lines up exactly with a structural population identified elsewhere in this study:

Across the dominant population of 10,499 documents the recovered metadata names the tools that touched the files — OmniPage OCR, a Processing-CLI assembly step, and pypdf; the OmniPage → Processing-CLI → pypdf ordering is the assembly sequence those fingerprints most plausibly imply, not a recorded log — the metadata establishes which toolchain processed the files more firmly than the exact order in which it did. But the metadata recovery does more than name it: the 425 ReportLab files and the 14 Word 2007 originals are independently generated populations the visible metadata strip had completely hidden — and each maps one-to-one onto a structural cohort we isolated from the bytes alone. The provenance the active metadata appears to remove is not merely recoverable; it corroborates the pipeline partition from an entirely separate signal. The full cohort catalog and a pipeline diagram are in Appendix C.

Finding 5 — Data the Renderer Doesn't Show

96.7% of documents carry content that exists in the file but is never shown on screen — invisible text, compressed hidden objects, and orphaned metadata a machine reads and a human never sees.

Open one of these documents and you see a scanned page. The file contains far more. 16,414 documents (96.7%) carry data present in the file but never painted to screen — text, objects, and metadata a human reader never encounters but a machine does:

• Invisible text (83.4%) — a text layer drawn in PDF rendering mode 3 (invisible): the OCR output laid behind the page image. Humans see the scan; machines read this layer.
• OCR-divergent text (18.6%) — where that layer does not match the image (Finding 7).
• Hidden objects (61.9%) — objects packed inside compressed /ObjStm streams, invisible to byte-level inspection without decompression.
• Orphaned objects (96.1%) — superseded objects (including the original /Info from Finding 4) retained in the file.

Finding 7 — Reality Drift: Human-Visible vs Machine-Readable

On 18.6% of documents the machine-readable text layer diverges from the visible page image — the human view and the machine view are measurably different records.

3,159 documents (18.6%), across 4,243 individual pages, contain a hidden OCR text layer that does not match the rendered image — measured by word-overlap (Jaccard) between what the page shows and what its text layer says. This is the single most consequential finding for automated use of the release:

• A human investigator reads the image.
• A search index, e-discovery tool, or AI/RAG pipeline reads the text layer.
• When they disagree, automated analysis silently ingests text that is not what the document visibly says — degrading search and corrupting any AI summarization or retrieval built on the corpus.

How this is measured. For each scanned page (up to five per document) the engine re-OCRs the rendered image with Tesseract and compares the result to the embedded text layer as normalized word sets (lower-cased, punctuation-stripped). A page is counted as divergent only when the Jaccard word-overlap falls below 0.3 — i.e. more than roughly 70% of words differ — and only when both layers carry real text (≥5 embedded and ≥6 re-OCR'd words, so blank and figure-only pages are excluded). The 0.3 bar is deliberately conservative: it flags substantial textual divergence, not transcription noise such as a single misspelled name. It establishes that the two text streams differ, not which one is correct.

Most affected documents drift on a single page, but the tail runs deep — some carry mismatches across a dozen pages:

Finding 8 — The Hidden Text Layer Often Says More Than the Page Shows

Where the two layers diverge, the hidden text is usually cleaner and richer than the visible page — exposing born-digital email headers on 2,248 pages the rasterized image degrades.

Reality drift (Finding 7) measures that the hidden text layer and the visible image disagree. We went further and examined how they disagree, across all 4,243 divergent pages. The pattern is consistent and consequential: the machine-readable text layer is frequently cleaner and more complete than the page a human sees, and it routinely exposes born-digital structure the rasterized image degrades or hides.

• 53% expose email header structure. On more than half of the divergent pages the hidden text layer contains From: / To: / Subject: / Date: / Attachments: fields — these are born-digital emails that were rendered to page images. The header text lives in the machine-readable layer even where the visible image is degraded. Email structure is widespread across the corpus — 8,702 documents (51.3%) carry From/To/Subject/Date fields somewhere — but these 2,248 pages are the consequential subset: the headers sit in the hidden layer on precisely the pages whose visible image disagrees with it, so the machine reads email metadata the human record degrades.
• 25% of the time the hidden layer is materially richer than re-OCR of the visible image — the text a machine ingests contains more than the page presents to a reader.
• Email-encoding residue survives. Measured across the full corpus, 70 documents (0.4%) carry base64 fragments and 57 (0.3%) carry quoted-printable (=20, =0A) in the extracted text — raw email transport encoding that should never reach a reader. Small in number, but an unambiguous fingerprint of an email-to-image conversion that left machine-only artifacts in the text layer.
• The divergence is not marginal: the median word-overlap between hidden text and visible image on these pages is 0.16 (1.0 would be identical).

The forensic significance is direct. A person reviewing these documents reads the image. A search index, an e-discovery platform, or an AI/RAG pipeline reads the hidden text layer — and for thousands of pages that layer says something different, and often more, than the visible record. (We report the existence and shape of this divergence, not its specific contents.)

Finding 9 — A Digital-to-Image Transformation Workflow

Uniform low-entropy rasters, near-zero page skew, a fixed 96-DPI render size, zero camera/scanner JPEGs, and no embedded fonts converge on one conclusion: the corpus was rendered to page images and OCR'd, not emitted as native documents.

The structural evidence converges on a single observable conclusion: the corpus underwent a digital-to-image transformation workflow before release — content rendered to page images, OCR-captured, and re-assembled, rather than emitted as native digital documents. The signals:

Three independent measurements point the same way:

• Image rasters are extraordinarily uniform. Across 29,870 image XObjects the mean entropy is 1.01 (median 1.02), with 49% below 1.0 — heavily-compressible, low-variation raster data unlike the texture and sensor noise of native paper scanning.
• Skew is uniform and near-zero. On a rendered sample we measured page skew directly: 91% of pages sit within 0.5° of true horizontal, and the skew spread within a multi-page document averages 0.55°. Physical scanning of paper introduces per-page skew variation; this consistency is the signature of programmatic rendering, not a feed scanner.
• No born-digital structure, redundant color encoding. 99.9% carry no structure tree, no document embeds a font or attachment, and 33% store grayscale content in an RGB color space — a re-encoding artifact of a rasterization pass.

Taken together — uniform low-entropy rasters, near-zero uniform skew, redundant color encoding, and an OCR text layer in place of real fonts — the signature is a render-to-image pipeline applied at scale. We note one measurement that did not hold: page borders are not uniformly flat (border pixel variance is non-trivial), so we make no claim about the absence of edge artifacts; the conclusion rests on the skew, entropy, and structural evidence above.

The image and font encoding nail it down further. We extracted image and font tables directly from a sample:

816×1056 is 8.5″×11″ multiplied by exactly 96 — a digital page rendered to raster at a fixed resolution, not paper measured by a scanner. Combined with the complete absence of embedded fonts across all 16,971 files (every glyph is drawn with non-embedded standard fonts the OCR layer references), the encoding describes a render-to-image assembly line, not a scanning operation.

The zero-JPEG result is worth dwelling on, because the choice is consequential. A JPEG (DCTDecode) image is the native output of every camera and most document scanners, and it travels with an EXIF/IPTC/XMP sidecar — camera model and serial, operator, software, timestamps, and frequently GPS coordinates. Re-encoding every photographic page as a bare FlateDecode bitmap discards that sidecar wholesale. Whether by design or as a side effect of the rasterization step, the format choice forecloses the richest channel of source-device metadata a release like this could otherwise leak — consistent with the same total metadata strip seen in Finding 4.

A small structural tell corroborates this. 619 documents (3.6%) carry a FontDescriptor with a non-negative /Descent value — invalid per ISO 32000, which defines /Descent as the depth below the baseline and requires it to be negative. These descriptors describe real Windows typefaces (ArialMT in 478 files, TimesNewRomanPSMT in 212, CourierNewPSMT in 113) that the pipeline referenced without embedding, and 98% of every document that carries such a descriptor has the defect — a consistent fingerprint of the same automated font-handling step, not random corruption. (These descriptors live inside compressed object streams, invisible to byte-level inspection; our engine reads into the object streams to find them.)

A deliberate limit: this is an observation about process, not content. The structure shows a digital-to-image transformation occurred before release. It does not, on its own, establish that the underlying content was altered — that requires evidence beyond PDF structure. We report the technical finding and stop short of any claim about fabrication.

Finding 12 — There Is No Single Canonical Reading

Read together, the findings make one argument: this corpus has no single canonical reading — the page a human sees and the machine-interpreted layer that travels with it are two different representations that routinely diverge, and which one governs depends on the context.

The preceding findings are usually treated as separate defects. Read together, they make one structural argument that is the central result of this study:

For this corpus there is no single authoritative version of a document. The page a human sees and the machine-interpreted layer that travels with it are two different representations — and across thousands of documents they say something different from each other, or cannot be agreed upon at all. Which one governs is a matter of context, not of the file: a court or produced exhibit treats the rendered page as authoritative; a search index or AI/RAG system treats the text layer as authoritative. What this release removes is the safe assumption that the two are the same.

Every content-integrity signal we measured is a different way the same thing is true:

This reframes what "reading" the Epstein files even means. A person opens a page image. A search index, an e-discovery platform, or an AI/RAG system ingests the text layer, the object graph, and the orphaned metadata — a different representation, one that for nearly one document in five does not match the visible page, and that no two PDF parsers fully agree on. There is no single canonical reading of this corpus: there is the human view and there is the machine view, and the gap between them is measurable, widespread, and — for automated analysis at scale — the most important property of the release.

The limit holds here too: that the machine layer diverges from the page is an observable technical fact. Whether any specific divergence reflects intent, OCR error, or conversion artifact requires evidence beyond PDF structure. We report the divergence and its scale, not a motive.

Finding 13 — The Numbering Shows a 2.4%-Complete Production

The Bates numbering is page-perfect and reuse-free, yet the released pages occupy just 2.4% of their 2.85-million-page numbered range, in 16 islands with three contiguous multi-hundred-thousand-page gaps.

Every file is named by a Bates number (EFTA + eight digits), stamped onto the page by the dedicated per-page overlay characterized in Finding 11. That makes the corpus a sequence — and the sequence proves the numbering is strictly per page: for 16,914 of 16,970 consecutive document boundaries, the next document's first Bates number equals the previous document's first number plus its exact page count, with zero overlaps anywhere in the corpus. The documents were sliced from continuous scan runs, the release preserves production order, and no Bates number is reused. It is a clean, mechanically-produced numbering — which is precisely what makes its gaps measurable.

The 16,971 released documents total 67,143 numbered pages, but their Bates numbers run from EFTA00000001 to EFTA02853705 — a numbered range of 2,853,705 pages. The release therefore accounts for 2.4% of its own numbering range; roughly 2.79 million numbered pages inside that range are absent from the release. And the absences are not spread evenly — the released documents collapse into 16 contiguous islands, with 87% of all documents (14,723) packed into the first ~40,000 Bates numbers, followed by three contiguous deserts:

The limit applies with full force here. What our data establishes is structural: the released PDFs occupy 2.4% of a page-contiguous, reuse-free Bates range, in sixteen islands, with three multi-hundred-thousand-page contiguous gaps. What it cannot establish is the cause of the absences — numbered pages may have been withheld, redacted in full, released only as non-PDF native exhibits (the video and spreadsheet files we did not scan), or assigned to separate productions outside this corpus. We report the shape and scale of what is absent, not the reason for it.

Implications for AI & RAG Systems

The findings above are not only a record of how the release was made; together they describe a substrate that is actively hostile to automated reading. Anyone who indexes, searches, or feeds this corpus to a retrieval or language-model pipeline inherits every one of these properties. The consequences are concrete:

1. You ingest the hidden OCR layer, not the page a human sees. The only machine-readable content is the invisible text drawn behind the image (Finding 5), and on 18.6% of documents that layer diverges from the visible page (Finding 7) — median word-overlap 0.16 on the divergent pages. A model can answer fluently from text the source image does not support, with no visible cue that the answer is ungrounded.
2. There is nothing to chunk on. 99.9% of documents are untagged — no structure tree, headings, reading order, or /Alt text (Finding 11). Structure-aware chunking degrades to raw OCR text flow, whose reading order is ambiguous on 44.7% of documents (Finding 6), so chunk boundaries fall mid-thought and retrieval recall suffers.
3. Your corpus can depend on your parser. On 61.9% of files independent PDF libraries disagree about how to decode the document — its declared version and the recovery path that follows (Finding 6) — and a tool that takes the wrong path can extract different text. Pin one parser and version it, or two teams can build measurably different indexes from the identical release.
4. The shipped text is provisional, not authoritative. Every page is a fixed 96-DPI raster (Finding 9); at that resolution a modern OCR engine re-run over the same images yields a different — usually better — text layer than the one bundled in the file. Treat the embedded OCR as a draft and re-OCR before indexing if accuracy matters.
5. Naive object walks surface buried content. 96.1% of files retain orphaned objects, including superseded /Info dictionaries and data in compressed object streams (Finding 5). An extractor that walks every object — not just the live page tree — ingests superseded and non-rendered content; decide deliberately whether that belongs in your index.
6. The release is a 2.4% slice — absence is not evidence of absence. The Bates numbering shows the released pages occupy just 2.4% of their numbered range (Finding 13). A system that returns “no documents about X” is reporting the contents of this slice, not of the underlying production; do not let a model infer that something did not happen from its absence here.

A practical checklist for anyone building on this corpus:

None of this concerns document content or its truth. It concerns whether an automated reader can faithfully recover what the page shows — and for this corpus, by construction, it often cannot without deliberate countermeasures.

What This Means

1. Provenance is partly recoverable, partly gone. Active metadata is stripped, but the OmniPage→Processing-CLI toolchain, the dated processing waves, and a few original 2013 dates survive in orphaned objects.
2. The release is a render-to-image production, processed in batches by two pipelines — an observation about process, not a claim about content.
3. For nearly one document in five, the machine interpretation differs from the visible record: the OCR text layer diverges from the page image, and there is no semantic layer to fall back on. Any party indexing, searching, or feeding this corpus to an AI system is, for thousands of documents, operating on text that does not match what the page shows.
4. The release is a small, clustered slice of its own numbering. The Bates sequence is page-perfect and reuse-free, yet the released pages occupy just 2.4% of their numbered range — the documents fall into sixteen islands with three contiguous, multi-hundred-thousand-page gaps. The structural absence is precise; its cause is not something PDF forensics alone can resolve.

These are exactly the conditions a multi-axis forensic engine is built to surface — and they are invisible to malware-signature scanning, which would correctly report this entire corpus as clean.