Epstein Files - Complete Dataset Audit Report

Generated: 2026-02-16 | Scope: Datasets 1–12 (VOL00001–VOL00012) | Total Size: ~220 GB

Background

The Epstein Files consist of 12 datasets of court-released documents, each containing PDF files identified by EFTA document IDs. These datasets were collected from links shared throughout this Lemmy thread, with Dataset 9 cross-referenced against a partial copy we had downloaded independently.

Each dataset includes OPT/DAT index files — the official Opticon load files used in e-discovery — which serve as the authoritative manifest of what each dataset should contain. This audit was compiled to:

1. Verify completeness — compare every dataset against its OPT index to identify missing files
2. Validate file integrity — confirm that all files are genuinely the file types they claim to be, not just by extension but by parsing their internal structure
3. Detect duplicates — identify any byte-identical files within or across datasets
4. Generate checksums — produce SHA256 hashes for every file to enable downstream integrity verification

Executive Summary

Dataset Overview

                      EPSTEIN FILES - DATASET SUMMARY
  ┌─────────┬──────────┬───────────┬──────────┬─────────┬─────────┬─────────┐
  │ Dataset │  Volume  │   Files   │ Expected │ Missing │ Corrupt │  Size   │
  ├─────────┼──────────┼───────────┼──────────┼─────────┼─────────┼─────────┤
  │    1    │ VOL00001 │    3,158  │   3,158  │    0    │    0    │  2.5 GB │
  │    2    │ VOL00002 │      574  │     574  │    0    │    0    │  633 MB │
  │    3    │ VOL00003 │       67  │      67  │    0    │    0    │  600 MB │
  │    4    │ VOL00004 │      152  │     152  │    0    │    0    │  359 MB │
  │    5    │ VOL00005 │      120  │     120  │    0    │    0    │   62 MB │
  │    6    │ VOL00006 │       13  │      13  │    0    │    0    │   53 MB │
  │    7    │ VOL00007 │       17  │      17  │    0    │    0    │   98 MB │
  │    8    │ VOL00008 │   10,595  │  10,595  │    0    │    0    │   11 GB │
  │    9    │ VOL00009 │  531,282  │ 531,307  │   25    │    3    │   96 GB │
  │   10    │ VOL00010 │  503,154  │ 503,154  │    0    │    0    │   82 GB │
  │   11    │ VOL00011 │  331,655  │ 331,655  │    0    │    0    │   27 GB │
  │   12    │ VOL00012 │      152  │     152  │    0    │    0    │  120 MB │
  ├─────────┼──────────┼───────────┼──────────┼─────────┼─────────┼─────────┤
  │  TOTAL  │          │1,380,939  │1,380,964 │   25    │    3    │ ~220 GB │
  └─────────┴──────────┴───────────┴──────────┴─────────┴─────────┴─────────┘

Notes

• DS1: Two identical copies found (6,316 files on disk). Byte-for-byte identical via SHA256. Table above reflects one copy (3,158). One copy is redundant.
• DS2: 699 document IDs map to 574 files (multi-page PDFs)
• DS3: 1,847 document IDs across 67 files (~28 pages/doc avg)
• DS5: 1:1 document-to-file ratio (single-page PDFs)
• DS6: Smallest dataset by file count. ~37 pages/doc avg.
• DS9: Largest dataset. 25 missing from OPT index, 3 structurally corrupt.
• DS10: Second largest. 950,101 document IDs across 503,154 files.
• DS11: Third largest. 517,382 document IDs across 331,655 files.

EFTA00709804    EFTA00823221    EFTA00932520
EFTA00709805    EFTA00823319    EFTA00932521
EFTA00709806    EFTA00877475    EFTA00932522
EFTA00709807    EFTA00892252    EFTA00932523
EFTA00770595    EFTA00901740    EFTA00984666
EFTA00774768    EFTA00912980    EFTA00984668
EFTA00823190    EFTA00919433    EFTA01135215
EFTA00823191    EFTA00919434    EFTA01135708
EFTA00823192

File Type Verification

Two levels of verification performed on all 1,380,939 files:

1. Magic Byte Detection (file command) — All files contain valid %PDF- headers. 0 mislabeled.
2. Deep PDF Validation (pdfinfo, poppler 26.02.0) — Parsed xref tables, trailer dictionaries, and page trees. 3 structurally corrupt (Dataset 9 only).

Duplicate Analysis

• Within Datasets: 0 intra-dataset hash duplicates across all 12 datasets.
• Cross-Dataset: All 1,380,939 SHA256 hashes compared. 0 cross-dataset duplicates — every file is unique.
• Dataset 1 Two Copies: Both copies byte-for-byte identical (SHA256 verified). One is redundant (~2.5 GB).

Integrity Verification

SHA256 checksums were generated for every file across all 12 datasets. Individual checksum files are available per dataset:

To verify any file against its checksum:

shasum -a 256 <filename>

If you’d like access to the SHA256 checksum files or can help host them, send me a DM.

Recommendations

1. Remove Dataset 1 duplicate copy — saves ~2.5 GB
2. Document the 25 missing Dataset 9 files — community assistance may help locate these
3. Preserve OPT/DAT index files — authoritative record of expected contents
4. Distribute SHA256SUMS.txt files — for downstream integrity verification

Report generated as part of the Epstein Files preservation and verification project.

@wild_cow_5769:matrix.org If someone has a group working on finding the dataset.

There are billions of people on earth. Someone downloaded dataset 9 before the link was taken down. We just have to find them :)

Holy shit

The entire Court Records and FOIA page is completely gone too! Fuckers!

some bad news, it looks like the data 9 zip file link doesn’t work anymore. They appear to have removed the file so my download stopped at 36gb. I’m not familiar with their site so is this normal for them to remove the files and maybe put them back again once they’ve reorganized them and at the same link location? or are we having to do the scrape of each pdf like another user has been doing?

While I feel hopeful that we will be able to reconstruct the archive and create some sort of baseline that can be put back out there, I also cant stop thinking about the “and then what” aspect here. We’ve see our elected officials do nothing with this info over and over again and I’m worried this is going to repeat itself.

I’m fully open to input on this, but I think having a group path forward is useful here. These are the things I believe we can do to move the needle.

Right Now:

1. Create a clean Data Archive for each of the known datasets (01-12). Something that is actually organized and accessible.
2. Create a working Archive Directory containing an “itemized” reference list (SQL DB?) the full Data Archive, with each document’s listed as a row with certain metadata. Imagining a Github repo that we can all contribute to as we work. – File number – Dir. Location – File type (image, legal record, flight log, email, video, etc.) – File Status (Redacted bool, Missing bool, Flagged bool
3. Infill any MISSING records where possible.
4. Extract images away from .pdf format, Breakout the “Multi-File” pdfs, renaming images/docs by file number. (I made a quick script that does this reliably well.)
5. Determine which files were left as CSAM and “redact” them ourselves, removing any liability on our part.

What’s Next: Once we have the Archive and Archive Directory. We can begin safely and confidently walking through the Directory as a group effort and fill in as many files/blanks as possible.

1. Identify and dedact all documents with garbage redactions, (remember the copy/paste DOJ blunders from December) & Identify poorly positioned redaction bars to uncover obfuscated names
2. LABELING! If we could start adding labels to each document in the form of tags that contain individuals, emails, locations, businesses - This would make it MUCH easier for people to “connect the dots”
3. Event Timeline… This will be hard, but if we can apply a timeline ID to each document, we can put the archive in order of events
4. Create some method for visualizing the timeline, searching, or making connection with labels.

We may not be detectives, legislators, or law men, but we are sleuth nerds, and the best thing we can do is get this data in a place that can allow others to push for justice and put an end to this crap once and for all. Its lofty, I know, but enough is enough. …Thoughts?

where did the party move?

is anyone else having issues getting dataset 10 to start downloading? it has been sittiing at 0 percent for a day while everything else is done and seeding. it shows connections to peers, rechecking does nothing, deleting and re-adding does nothing, asking tracker for more peers does nothing

I’m in the process of downloading both dataset 9 torrents (45.63 GB + 86.74 GB). I will then compare the filenames in both versions (the 45.63GB version has 201,358 files alone), note any duplicates, and merge all unique files into one folder. I’ll upload that as a torrent once it’s done so we can get closer to a complete dataset 9 as one file.

In regard to Dataset 9, it’s currently being shared on Dread (forum).

I have no idea if it’s legit or not, and Idc to find out after reading about what’s in it from NYT.

Does anyone have an index of filenames/links from the DOJ website scraped?

Edit, specifically for DataSet 9.

I’ve hopped on the 10 mag, will be seeding all night and then some. This might be one of the healthiest swarms I’ve ever seen

I was quick to download dataset 12 after it was discovered to exist, and apparently my dataset 12 contains some files that were later removed. Uploaded to IA in case it contains anything that later archivists missed. https://archive.org/details/data-set-12_202602

Specifically doc number 2731361 and others around it were at some point later removed from DoJ, but are still within this early-download DS12. Maybe more, unsure

I’m working on a different method of obtaining a complete dataset zip for dataset 9. For those who are unaware, for a time yesterday there was an official zip available from the DOJ. To my knowledge no one was able to fully grab it. But I believe the 49Gb zip is a partial of that before downloads got cut. It’s my thought that this original zip likely contained incriminating information and it’s why it got halted.

What I’ve observed is that Akamai still serves that zip sporadically in small chunks. It’s really strange and I’m not sure why it does, but I have verified with strings that there are pdf file names in the zip data. I’ve been able to use a script to pull small chunks from the CDN across the entire span of the file’s byte range.

Using the 49GB file as a starting point I’m working on piecing the file together, however progress is extremely extremely slow. If there is anyone willing to team up on this and combine the chunks please let me know.

How to grab the chunked data:

Script link: https://pastebin.com/ZqZGqkiH

or

Script with progress visualization: https://pastebin.com/UiCeTe3p

For the script with the progress visualization you will probably have to:

pip install rich

Grab DATASET 9, INCOMPLETE AT ~48GB:

 magnet:?xt=urn:btih:0a3d4b84a77bd982c9c2761f40944402b94f9c64&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce 

Then name the downloaded file 0-(the last byte the file spans).bin

So for example the 48 GB file it would be: 0-48995762175.bin

Next to the python script make a directory called: DataSet 9.zip.chunks

Move the renamed first byte range 48 GB file in to that directory.

Make a new file next to the script called cookies.txt

Install the cookie editor browser extension (https://cookie-editor.com/)

With the browser extension open go to: https://www.justice.gov/age-verify?destination=%2Fepstein%2Ffiles%2FDataSet+9.zip

The download should start in your browser, cancel it.

Export the cookies in Netscape Format. They will copy to your clipboard.

Paste those in your cookies.txt, save and close it.

You can run the script like so:

python3 script.py \
  'https://www.justice.gov/epstein/files/DataSet%209.zip' \
  -o 'DataSet 9.zip' \
  --cookies cookies.txt --retries 3 \
  --backoff 5.0 \
  --referer 'https://www.justice.gov/age-verify?destination=%2Fepstein%2Ffiles%2FDataSet+9.zip' \
  -t 8 -c 2048

Script Options:

• -t - The number of concurrent threads to use which results in trying that many byte ranges at the same time.
• -c - The chunk size to request from the server in MB. This is not always respected by the server and you may get a smaller or larger chunk, but the script should handle that.
• --backoff - The backoff factor between failures, helps prevent Akimai throttling your requests.
• --retries - The number of times to retry a byte range for that iteration before moving on to the next byte range. If it moves on it will come back to it again on the next loop.
• --cookies - The path to the file containing your Netscape formatted cookies.
• -o - The final file name. The chunks directory is derived from this so make sure it matches the name of the chunk directory that you primed with the torrent chunk.
• --referer - Just leave this for Akimai, set the referer http header.

There are more options if you tun the script with the --help option.

If you start to receive HTML and or HTTP/200 responses then you need to refresh your cookie.

If you start to receive HTTP/400 responses then you need to refresh your cookie in a different browser, Akamai is very fussy.

A VPN and multiple browser might be useful to change your cookie and location combo.

Heads up that the DOJ site is a tar pit, it’s going to return 50 files on the page regardless of the page number your on seems like somewhere between 2k-5k pages it just wraps around right now.

Testing page 2000... ✓ 50 new files (out of 50)
Testing page 5000... ○ 0 new files - all duplicates
Testing page 10000... ○ 0 new files - all duplicates
Testing page 20000... ○ 0 new files - all duplicates
Testing page 50000... ○ 0 new files - all duplicates
Testing page 100000... ○ 0 new files - all duplicates

for DS9, does anyone have the following files:

  EFTA00709804
  EFTA00709805
  EFTA00709806
  EFTA00709807
  EFTA00770595
  EFTA00774768
  EFTA00823190
  EFTA00823191
  EFTA00823192
  EFTA00823221
  EFTA00823319
  EFTA00877475
  EFTA00892252
  EFTA00901740
  EFTA00912980
  EFTA00919433
  EFTA00919434
  EFTA00932520
  EFTA00932521
  EFTA00932522
  EFTA00932523
  EFTA00984666
  EFTA00984668
  EFTA01135215
  EFTA01135708

If so, please DM me them and then I can include them in my master archive.