CSV vs JSON in Your X Archive: What Each Format Can Actually Do
Open an X archive and you will find two families of files mixed together: a set of .csv tables and a set of .js files. The names look similar. The capabilities are not. Pick the wrong one and you either lose fields or reach a wrong conclusion, while assuming the data simply looks that way.
The difference is whether structure can be expressed
CSV is two-dimensional: rows and columns. It handles lists where every row is the same kind of record, and it cannot express hierarchy. JSON is a tree. Nesting is the point.
| Dimension | CSV | JSON |
|---|---|---|
| Structure | Flat table, one row per item | Nested tree, any depth |
| How to open | Any spreadsheet app | A parser or a text editor |
| Nested entities | Flattened into text, partly lost | Fully preserved |
| Questions it fits | Counts, distribution, filtering | Relationships, structure, field-level checks |
| Manual review | Direct, readable as-is | Needs formatting before it reads well |
The nested entities row is the one that matters. A tweet with images can carry several size variants, a media type and the original link in JSON. In CSV those are usually squeezed into a single field or dropped outright.
What CSV answers well
Anything you can phrase as count it or group it belongs in CSV. You will use it to answer questions like: how many tweets are there in total, which year was the heaviest, which posts contain a given word, what the language mix looks like, whether posting density in one period is unusual. These take seconds in a spreadsheet, need no code and go wrong rarely.
CSV has an underrated advantage too. You can eyeball real rows directly, which is very useful when you want to confirm your filter conditions behave as intended.
What JSON answers well
Anything that walks down a structure belongs in JSON. For example: which tweet does this one reply to, which accounts were mentioned, what is the real domain behind a shortened link, how many media files a single tweet carries. Those answers live in the hierarchy, and CSV flattens them on export.
The .js files in the archive are not code. X writes them as JSON wrapped in an assignment so they can be read locally without a server. Open one in a text editor and you will see a leading assignment statement. Strip that layer and standard JSON remains. That is also why double-clicking often fails while a text editor shows everything.
Three selection mistakes that show up most
- Using CSV for relationship analysis. Questions like who gets mentioned most can only be approximated with text matching in CSV, and the result runs low. Mentioned accounts are a distinct field in JSON and part of a text blob in CSV.
- Using JSON for simple counts. Writing code is fine if that is your workflow, but most people just want a total when they open the file, and CSV is both faster and less error-prone there.
- Treating a mismatch as corrupted data. Different definitions explain it more often: missing media fields on retweets and replies, different item type coverage, different timezone handling. The check order is in the next section.
When the two formats disagree
Rule out three things in order and most gaps resolve. First, item coverage: CSV does not include every type, and likes and direct messages usually live in their own files. Second, field completeness: retweets and replies often lack media fields in CSV, so counts match while content is thinner. Third, timezone handling: the same timestamps can land in different date groups, and items near a day boundary show it first.
Once those three are ruled out, question the data itself. Doing it in that order saves a lot of time.
Choosing by the question you are asking
In practice you do not have to pick one. Use CSV for a fast pass over anything list-shaped, and go back to JSON for structural checks, with the two cross-checking each other. If you plan to parse a large archive locally, the approach in browser-side parsing is a useful reference, and the file and field layout is described in what is inside the archive. For storage, start with storing an archive safely.
About Digital Footprint Health
Digital Footprint Health (digital-footprint-health.shop) handles the format question for you. Upload your X data archive and the tool parses every tweet and media file on your own device, returning a score from 0 to 100 and flagged items grouped by category. It is read-only, uploads nothing and never asks for account access, and you do not need to work out the CSV and JSON difference first. The scoring model is explained in using the health score, and label meanings are in risk labels. Scope and pricing are on the pricing page, the free check starts on the homepage, and everything else is on the blog.
Frequently Asked Questions
Why won't spreadsheet software open the .js files in my archive?
Because they are not JavaScript code. They are JSON data wrapped in an assignment. X writes them that way so the files can be read locally without a server. Open one in a text editor and you will see a leading assignment statement. Strip that outer layer and what remains is standard JSON that any parser can read.
If I only want to count tweets, which format should I use?
CSV. tweets.csv holds one row per tweet, so counting, grouping by date and filtering by keyword take seconds in a spreadsheet with no code. Doing the same in JSON means parsing a structure and walking it. Counts, date distribution and language distribution all sit in CSV territory.
What only exists in the JSON?
The full nested structure. A tweet in JSON can carry complete entities: the list of mentioned accounts, hashtags, expanded destination URLs, multiple size variants per media file, and the reply relationship. CSV flattens these into cell text, so multi-level structure gets merged or dropped, which is why CSV usually falls short for relationship analysis.
The two formats give different numbers. Is my data wrong?
Usually not. Three causes cover most of it: CSV is row-based and often lacks media fields for retweets and replies, so counts look the same while content is thinner; JSON contains item types that CSV does not export, with likes and direct messages living in their own files; and timezone handling differs, so the same timestamps can fall into different date groups. Rule those three out first.
Check your own X/Twitter footprint
Free on-device scan. Your archive never leaves your computer.
Start Free CheckRelated Reads
Can You Download Your X Archive on a Phone?
You can request your X data archive and receive the download link on a phone, but unzipping and analysing it there runs into real limits: file size, storage, the tools available, and memory. Three approaches each carry trade-offs, and there are specific traps to avoid when moving the file.
Don’t Just Delete: What You Lose by Skipping the Archive
Before you wipe old posts, read the archive once. The travel, the rants, the friend groups you forgot are a ten-year memoir. Here is how to read it and why delete-only misses things worth keeping.
X Archive Download Failed: Stuck Requests, Missing Emails, Broken ZIPs
An archive download usually breaks at one of four points: the request never queued, the email never arrived, the file is truncated, or the ZIP opens without tweet data. Here is the order to check them in, plus why stacking new requests makes the wait longer rather than shorter.