Updated Oct 13, 2026
By the end of a proper takeout you have 43 downloads in 43 folders. Some are one CSV per metric, some are a single enormous JSON file, and a few are thousands of photos. None of them agree on anything. Dates are in three formats, timezones differ, and no two services call the same thing the same name. Merging them is possible and occasionally necessary. It is also the step most people should skip, and the reason is not laziness: for most exports, keeping them separate costs you nothing and joining them introduces errors you will not notice. A workout logged at 07:00 in Tokyo and a run at 07:00 in Berlin are the same string and two different events. This guide covers both sides. If you want one file, work down from level 1 to level 4 and stop when it does what you need. If you just want your data safe, <a href="/guides/backup-your-exports">back it up</a> and read the first section, which is the useful bit.
Most readers do not, and the merge is where data quietly goes wrong. Before combining anything, be clear about what you want the result to do.
There are three honest answers. "I want to be able to find a specific thing without opening 43 folders" is solved by an index file, not by a merge. "I want to count my activity across Strava and Garmin" is a real join, because the rows genuinely describe the same thing. "I want one file of my entire life" sounds appealing and produces a mess that answers no question.
This is the part that catches people, and it is why "just combine them" is not a five minute job. Four things differ between services, and three of them silently produce wrong answers rather than visible errors.
This is the setup most people should stop at. You get one workbook you can actually search, and you keep every export exactly as the service sent it.
The point is that nothing has been transformed. Every row still means what it meant in the original file, so you can always go back and check against the source. This is the level where you cannot quietly corrupt your own archive.
When every export is a flat CSV with the same columns, merging is genuinely easy and this is the right level. It is genuinely only valid when the files share a schema, so check the headers before you start.
A single file database handles files that a spreadsheet cannot: too many rows for one sheet, different shapes per source, or a JSON structure that needs flattening first.
SQLite is the sensible default. It is a single file, it is free, and the whole database is one thing to back up. DuckDB is the better tool if you want to query the files directly in their original format without importing them at all, which saves an enormous amount of work when your exports are large JSON.
Only worth it if you are doing this repeatedly, or if the data is genuinely too big for the tools above. A short Python script with pandas will read every CSV in a folder, normalise the dates, and write one combined file.
The script is the easy part. The value is in the handful of decisions it forces you to make explicitly: what "distance" means, which timezone a naive timestamp is in, and what to do with rows that match no other service. Those decisions are the same ones a database forces, and there is no way to skip them.
If you read one section of this guide, read this one. Every merge that goes wrong goes wrong here.
An export giving you "2026-03-15 07:00:00" with no zone is not UTC and is not necessarily your local time at the time. It is whatever the service decided to write, which varies by field within the same file. An export giving you 1773500000 is UTC by definition, and it is usually right. An export giving you an offset alongside the timestamp is the only one where you can be certain.
After a merge, duplicates are normal and mostly harmless. Sync between a watch and a service produces the same workout twice, sometimes with slightly different values because each recorded it separately.
Do not delete them on principle. Keep both, add a column marking which one you kept and which you discarded, and keep the reason. Which record is more accurate depends on the device, and the answer is not always the service.
Some merges are not worth attempting, and it is worth saying which.
Photos are the clearest case. Your media exports are thousands of image files with EXIF timestamps, and merging them means deduplicating by hash across platforms, which is a real project rather than a guide. If you want one photo library, use a tool built for it rather than exporting and merging by hand.
Chat histories are the second. The formats differ so much that merging them produces a file you cannot read, and the analytical question people actually want answered, which messages happened when, is better served by one service at a time.
Anything containing credentials, tax records or medical data should be combined on an encrypted volume, not in a spreadsheet in your Downloads folder.
The practical steps here come from the documented behaviour of the export formats themselves rather than from any single vendor, and the per-service details are covered by the individual guides on this site.
If the files share the same columns, use your spreadsheet folder import, which reads every CSV in a directory and stacks them into one table. Add a "source" column before you start so you can tell which service each row came from. If the columns do not match, merging produces a table that is mostly empty cells, and you need a database instead.
Almost always a timezone mismatch. Some services store UTC, some store your local time at the moment of the event, and some give a UTC offset alongside a naive timestamp. Pick one timezone for the whole dataset, convert everything into it, and write down which one. Daylight saving is the other cause, because a local timestamp on the day the clocks change can be genuinely ambiguous.
For most people, no. One spreadsheet with one sheet per service gives you searchability without transforming anything, which means you cannot have quietly corrupted the data. Merging is worth it when two services genuinely describe the same events, such as the same run recorded on both a watch and Strava.
DuckDB for querying files directly in their original format without importing them, which matters when the exports are large JSON. SQLite for building a persistent database you can query repeatedly. A spreadsheet is enough until you have more rows than one sheet can hold, which is further out than most people expect.
Expect them. Sync between a watch and a service records the same workout twice, sometimes with slightly different values. Do not delete them on principle. Keep both rows, add a column marking which one you kept and which you discarded, and keep the reason, because which source is more accurate depends on the device rather than the service.