When you export YouTube history, Takeout lets you pick JSON or HTML. The choice looks cosmetic and is not. The two formats carry the same viewing events but encode the timestamp very differently, and that single difference determines whether any time-based analysis of your history is trustworthy. If you only read one thing here: choose JSON.
What each format actually is
The JSON export is structured data. Every viewing event is an object with named fields, and the timestamp is an ISO 8601 string that carries its own UTC offset. There is exactly one way to read it, and every parser reads it the same way.
The HTML export is a rendered web page meant for a human to scroll. Entries live in elements with the class content-cell. Inside one of those, the word 'Watched ' is a bare text node sitting before the links, the first link is the video, a later link is the channel, and the date is whichever remaining text node happens to contain a four-digit year. Nothing is labelled; the structure has to be inferred from position.
The timestamp problem
Here is the part that catches people. In the HTML export, the date is written the way your Google account displays dates — in your account's language, with localised month names and a local timezone abbreviation.
So the same view might be written as 'Jan 5, 2026, 8:31:04 PM EST' for one account and '5 de jan. de 2026, 20:31:04 BRT' for another. A parser has to recognise the language before it can read the date, and there is no field telling it which language to expect.
Our HTML parser handles the English format and the Portuguese 'DD de MMM de YYYY' form, including the BRT and BRST offsets. Anything else falls through to the browser's own date parser, which will either produce a wrong date or refuse the string entirely. If your account displays dates in German, Japanese, or Hindi and you exported HTML, your activity timeline may be silently wrong.
The JSON export has none of this ambiguity, because ISO 8601 is not localised.
Fragility beyond dates
Positional parsing is brittle in other ways too. The HTML export's markup is a Google implementation detail, not a documented format, and it has changed before. A layout change that a human reader would not even notice — an extra link, a reordered element — can break a parser that depends on 'the second anchor is the channel'.
HTML is also far heavier. The same history carries markup, inline styles, and repeated wrapper elements around every entry, so the file is several times larger than the JSON for identical information.
If you already have an HTML export
You do not necessarily have to redo the export. Our analyzer reads watch-history.html as well as watch-history.json, and will accept either from inside a .zip or .tgz archive without unpacking.
Check the results before trusting them. Look at the activity timeline and ask whether the date range matches your memory. If views are bunched into a single implausible day, or the range starts years later than you expect, the dates did not parse and you should re-export.
Re-exporting is not expensive. A history-only export is small and usually ready in minutes rather than hours, because you are asking for a few megabytes of text rather than the media-heavy products that make Takeout slow.
Choosing at export time
In Takeout, deselect everything, choose 'YouTube and YouTube Music', open the data selector, and narrow it to history. That single step is the difference between a few-megabyte download and an archive that includes every video you ever uploaded.
Then set the format to JSON where Takeout offers the choice. It is a dropdown people skip past, and it is the most consequential setting on the page for anyone who intends to analyse the result rather than skim it.
Checking whether your HTML dates parsed at all
If you already loaded an HTML export, the failure mode is quiet: you get charts, and the charts are wrong. There is no error, because an unparseable date usually falls back to something rather than nothing.
Three symptoms give it away. A large share of views landing on a single day, usually today, means the fallback produced the current date. An activity timeline that starts years later than you know you started watching means early entries failed and were discarded. An hour-of-day histogram that looks flat, with viewing spread evenly across 3am and 3pm alike, means the times are noise — real human viewing is never uniform across the clock.
If you see any of those, do not try to interpret the result. Re-export as JSON.
Why the size difference is not just cosmetic
The HTML export carries the same events wrapped in markup: a container per entry, inline styling, repeated class attributes, and link markup around every title and channel. The same history is several times larger than the equivalent JSON.
That matters because this analysis runs in your browser tab, on your device. A larger file means more memory to hold the parsed document and more work to walk it, and the gap is felt most on phones and older laptops — exactly the devices where a tab is most likely to be killed mid-analysis.
JSON parsing is also handled by the browser's native JSON reader, which is far faster than constructing a full DOM and querying it. On a large history the difference is the difference between a moment and a visible wait.
What to do if you cannot re-export
Occasionally re-exporting is not practical — you are working from an archive someone kept years ago, or from an account you no longer control.
In that case, load the HTML and treat the aggregate counts as usable while treating everything time-based as suspect. Total views, top channels, and the removed-video share do not depend on date parsing and will be correct. The activity timeline, the hour-of-day histogram, and anything described as a streak or a session do.
That split is worth knowing generally: in this dataset, counting is robust and timing is fragile. Every conclusion that depends on when something happened rests on one field being read correctly.