--
title: "Your 200MB Twitter Archive Is Mostly Thumbnails"
description: "Where the weight in a large Twitter archive actually goes, and why browsers choke on 30,000 files when they should not."
tags: ["privacy", "javascript", "webdev", "twitter"]
canonical_url: https://digital-footprint-health.shop/blog/huge-archive-200mb
A veteran X account exports a large Twitter archive of 200MB with 30,000 files after unzipping, and most online tools spin and die on it. That is not your account being unusual. Most tools were never designed for the size.
Here is the real breakdown of a 203MB archive from an account with 32,148 tweets:
- data/tweets.js: 38MB, one file, every tweet body and ID
- other data/*.js: about 6MB across 60-odd files for follows, likes, DMs
- data/tweets_media/: about 150MB across 26,000+ files, mostly thumbnails
- assets/ plus the offline viewer: about 9MB, display only
The distribution tells the whole story. One 38MB file needs parsing. The other 150MB is pictures.
Why tools crash
Two bad choices. Extracting every file into memory at once, or building a DOM node to preview each media file. Neither is required. Extract only data/tweets.js, parse it as a stream, and fetch media lazily when a user opens a specific tweet. With that design my 203MB archive peaked under 400MB of memory and parsed in 2 minutes 12 seconds on a 16GB laptop.
Where the weight comes from
Images and video dominate, because X generates several sizes per image and a four-photo tweet maps to a dozen files. Retweets and long replies come next: plain text, but each carries a metadata blob, and 30,000 of them add up. Then direct messages, which can occupy another few dozen megabytes.
File count and tweet count are only loosely related. I have seen an 8,000-tweet account export 1.2GB because the owner posted video constantly, and a 40,000-tweet account come in at 31MB because it was all text.
The three errors people hit
- Extraction fails or reports corruption. Usually an incomplete download, since X links expire and resumed transfers break. Request a fresh archive and pull it in one shot.
- The tab freezes. Implementation flaw, not your fault. Unzip manually and feed in only the data folder.
- The parsed tweet count is wrong. Check for split files: large accounts get tweets-part1.js, tweets-part2.js, and reading only the first silently loses half your history. This is the most common quiet failure I see.
Practical habits
Copy the download to an external drive immediately, compare the parsed count against your profile number, and avoid deeply nested extraction paths since Windows path limits drop media files silently.
Full breakdown: https://digital-footprint-health.shop/blog/huge-archive-200mb
