Merge FIT Files

Read directly, not converted first

FIT is a binary format. Open one in a text editor and you get nothing readable, which is why some track tools ask for a GPX and expect you to find a converter for the file your watch actually produced. GPXFIT skips that step.

GPXFIT decodes FIT with Garmin's official FIT SDK, running in your browser rather than on a server. So the merge takes .fit, .gpx and .tcx, and you can mix all three in one job when an activity was recorded across two different devices.

Other tools also merge FIT files directly, including client-side options, and Strava's own support page points to two of them for combining files. GPXFIT keeps a FIT recording's timer-pause boundaries intact through the merge (below), and says plainly what a FIT-to-GPX conversion loses instead of presenting the export as if nothing changed.

The output is GPX 1.1. Reading a FIT file and writing one are separate problems: writing means binary message definitions, a header whose declared length has to match the data, and a CRC over the whole file, and a file that gets any of that wrong can be rejected without much explanation. GPXFIT doesn't write FIT yet, and FIT file repair tracks where that work stands.

Pauses, and the part FIT does differently

This is the detail that decides whether your merged file is honest, and it's specific to FIT.

GPX has a structural way to mark a pause: a second <trkseg> element, so the break is explicit in the file's structure. The format doesn't force a recorder to write one on every stop and restart, but the option is there.

FIT doesn't work that way. The device stops writing position records and writes a timer event into a separate message stream. The records either side sit next to each other with nothing between them, so a parser that reads records alone sees one unbroken ride and draws a straight line through the cafe, the drive home, or the two hours you spent waiting for a mechanic.

GPXFIT reads the event stream, finds each point where the timer restarted after a stop, and starts a new segment there. In a 68-file test corpus (mostly real device recordings, with a handful of deliberately corrupted or synthetic fixtures mixed in), 9 of the 38 that decode with GPS had been stopped and restarted at least once. The per-file numbers, including how long each device sat stopped and what that does to the distance, are on the FIT pause data page.

The practical effect: distance is summed per segment, so the gap isn't counted as ground you covered, and segment-aware map viewers can draw a break instead of a connector.

What survives the merge, and what doesn't

Every point keeps its latitude and longitude, plus elevation and time where present. GPXFIT does not smooth, snap to roads, resample, or invent points to bridge a gap.

Those four are also all you get. A FIT file is denser than a GPX and the merged output is the thin part of it: heart rate, cadence, power, temperature, lap markers, developer fields and the session summary your head unit wrote are all absent from the result.

GPX can technically carry sensor data in extension fields, which is how a Strava export ends up with heart rate in it. GPXFIT's exporter doesn't write those fields, so the loss is real rather than a limitation of the format.

Worth deciding before you merge, not after. If the streams matter more than one continuous track, keep the originals and upload them as two activities. If the single track matters more, merge and accept the loss. Your original files aren't touched either way.

FIT files that won't merge

Three cases, and they need different responses.

No GPS in the file. Indoor trainer rides, pool swims, strength sessions and sensor-only recordings can be valid FIT files without position data. You get an explicit error naming the file, because there's no honest way to guess where it happened. 21 of the 68 files in the test corpus get this exact message, counting indoor sessions alongside settings and monitoring files that were never activities in the first place. 2 more also have no GPS but hit a decode error first, the next case below, so 23 of the 68 lack position data altogether.

The file fails its integrity check. Truncated recordings and corrupted transfers get rejected before anything is merged, rather than contributing half a ride you wouldn't notice was half. 4 of the 68 corpus files fail this way.

The file passes that check but the SDK hits an error partway through reading it. A header can be well-formed while something further in still trips an error, and that isn't always damage: two files in the test corpus fail this way because they use compressed-timestamp messages, a valid FIT feature this decoder doesn't support yet, not because they're broken. GPXFIT can't tell that case apart from real corruption, so it rejects both rather than merging in whatever got decoded before the error and calling it a complete ride. 5 of the 68 corpus files fail this way. Either kind of rejection points to FIT file repair for where that work stands.

Getting the merged file into Strava or Garmin Connect

Check timestamps first. Strava rejects a GPX with no time data, since it can't work out when the activity happened or how fast you were going. FIT Activity records are timestamped, but a GPX or TCX source may have missing time data. The File Inspector reports the start and end times it could read, which tells you whether timestamps exist at all, not what share of the points carry one.

Garmin Connect takes GPX as a course. If the goal is getting the route back onto the watch rather than logging the activity, you don't need a FIT file: import the GPX as a course and sync it.

Watch for overlap. If both devices recorded the same 10 minutes, you keep both copies in two segments and your total distance climbs to match. Trim one of them first. The trimmer takes GPX and TCX, so export the FIT as GPX in the File Inspector before trimming it.

Merging GPX or TCX files rather than FIT ones? The GPX merger is the same tool with the GPX side written up in more detail.