About DataUnpacker
Companies let you download your personal data. Then you open the download and find a 4GB ZIP with seventeen thousand files in it. Half are JSON, some are CSV, a few are HTML, and the rest seem to exist purely to ruin your afternoon.
DataUnpacker turns that pile into something you can actually look through. Upload your export, then browse it. It's free, and I'm the only person working on it.
Privacy, up front
Most of the processing happens in your browser. Remote debugging is a separate feature, and it's optional. Here's what it does:
- It's only on if you accept it. Declining the consent banner turns it off, and the viewers still work fine.
- If you accept, selected files from your export may be sent to my server. That means actual file contents, not just filenames or anonymous stats.
- Those files can contain personal information. Depending on the export, that could be messages, activity history or account details.
- Retention: 2 hours, then deleted.
- Changing your mind: You can decline the cookie banner by going to the privacy page and clicking the [cookie] button.
The full details are in the Privacy Policy. If you're not comfortable with any of this, decline. You don't owe me your data because I built a free tool.
Why remote debugging exists
I can't fix a file format I've never seen. Everything else follows from that.
Take Google Takeout. It covers dozens of services, and each one can export differently. Picking JSON or HTML in the export settings doesn't mean every service follows it. I don't use most of those services, so I have no way of generating realistic samples. I find out what the files look like when someone uploads one.
TikTok was the same. My own account gives me JSON, so that's what I built the parser around. Then someone uploaded a perfectly legitimate export made of TXT files. I didn't know TikTok did that. Knowing a file is TXT tells you nothing about where one record ends, what separates fields, or whether the URLs are wrapped in something strange. (They were.)
Then there's language. I'd assumed exports would use English filenames and field names, which was naive. Plenty of services localise everything: filenames, headings, dates, field names. The first time someone uploaded a Chinese Google Takeout, the viewer fell over. My error reporting back then was a Discord ping with a wall of Chinese text in it. I couldn't reproduce the problem or tell which file caused it. That's a big part of why the error reporting you see today is so detailed.
And sometimes the export isn't the problem at all. Safari refuses a valid ZIP. A 6GB archive runs the browser out of memory. Someone deletes half the files and uploads a single JSON. Someone uploads a Snapchat export to the Discord viewer. I now have specific errors for wrong platform, incomplete export, corrupted archive, unsupported format and genuine parser failure, because each of those needs handling without the whole site falling apart.
I first tried collecting only structural information in the browser, like file types, folder names and field names. That helped, up to a point. A scanner can tell me a field holds a URL. It can't tell me the URL is buried in a bizarre sequence of brackets, or which odd value is crashing the parser. Sometimes I need to see the real contents to know what's going on.
So when remote debugging is enabled, selected files go to my server, which runs deeper inspections to work out formats and structures. It doesn't fix anything automatically. It just lets me see the problem instead of staring at an error message, trying to reproduce something involving a Google service I've never used, in a language I don't speak, on a device I don't own.
This is also why viewers grow gradually. I don't have ten years of someone else's Google Fit data lying around to test with, so I add support as real exports show me what's out there. Some viewers are mature. Newer ones are still meeting new formats all the time.
Open source
The Google Takeout viewer is on GitHub under the MIT license. Nobody else should have to work this out from scratch. If you're another developer who has lost an afternoon to Google deciding one file should use a different format from all the others, you're welcome. Use it, study it, send fixes.
The point of all this
People should be able to understand what companies have collected about them without learning JSON or opening thousands of files by hand. Making that easy takes a lot of unglamorous work, and some of it is impossible without seeing the files that break things. Every format I figure out is one less thing that breaks for the next person.
Thanks for using DataUnpacker.
And to whichever engineer decided to put URLs inside << >>: I just want to talk.
The increasingly sleep-deprived developer of DataUnpacker