Convert TCX to GPX

TCX is Garmin's format and the ecosystem around it reads it fluently. Step outside that ecosystem and it becomes an obstacle: route planners, mapping tools, open-source navigation apps, club upload forms and a great deal of GIS software accept GPX and nothing else, because GPX is the format that predates all of them and describes only geography.

So the conversion is usually not a choice about data. It is a compatibility step taken because a specific destination refused the file, and the useful question is not whether to convert but what you will no longer have afterwards. The answer is most of what made it a training file, and it is worth reading the list before rather than discovering it when a chart comes up empty.

Per point: `<HeartRateBpm>`, `<Cadence>`, `<DistanceMeters>` and everything in the `<Extensions>` block — which is where running cadence, watts and the device's own instantaneous speed live. Per lap: `TotalTimeSeconds`, `DistanceMeters`, `MaximumSpeed`, `Calories`, `AverageHeartRateBpm`, `MaximumHeartRateBpm`, `Intensity` and `TriggerMethod`. Per activity: the lap divisions themselves, and any `<Creator>` block naming the device that recorded it.

That is not a partial list with a "and similar" at the end; those are the elements a TCX defines, and none of them is read. What remains is `<Time>`, the two halves of `<Position>` and `<AltitudeMeters>`, which is exactly the information a GPX trackpoint holds natively. The conversion is faithful about the route and silent about the workout, and it is better to know which of the two you are carrying forward.

The easy version of this explanation is that GPX cannot carry heart rate, and it is wrong. Base GPX 1.1 has no sensor fields, but the format is explicitly extensible, and Garmin's own TrackPointExtension namespace adds heart rate, cadence, temperature and more inside the `<extensions>` element of a trackpoint. Strava, Garmin Connect and most training platforms read it, and a GPX exported from a watch routinely contains it.

The output here contains no extensions block of any kind. Every trackpoint is written with latitude, longitude, an optional `<ele>` and an optional `<time>` and nothing else, because the converter reads all four GPS formats through one shared internal shape and that shape has no room for a sensor stream. The loss is a property of this conversion rather than of the destination format, and stating it that way is the difference between an accurate expectation and a wrong one.

Positions come through at six decimal places, about 11 centimetres, which is well inside the several metres of error a consumer receiver contributes. Altitude is copied from `<AltitudeMeters>` into `<ele>` with no rounding and no unit conversion, both being metres. Timestamps are copied verbatim rather than reformatted, so a Garmin file writing `2026-03-14T06:41:07.000Z` keeps its milliseconds and its UTC marker.

That last point makes the output a genuine recording rather than a course. A GPX with timestamps has a duration and a pace, and it uploads as a completed activity to anything that accepts GPX at all — which is the common reason for this conversion and the reason it works cleanly. What the receiving platform then computes from those times is its own arithmetic, and it will differ slightly from the numbers Garmin showed you, because Garmin was using the sensor streams that are no longer in the file.

A TCX groups trackpoints into laps, and laps are the structure a workout is read through: the split times, the recoveries, the per-interval averages. Those boundaries are flattened. Every lap's points are concatenated in order into a single `<trkseg>` inside a single `<trk>`, and nothing in the GPX marks where one ended.

GPX does have a segment concept, so in principle the laps could map onto `<trkseg>` divisions — but a GPX segment break conventionally means a gap in the recording, not a button press, and encoding laps that way would make every reader think the signal had dropped twelve times. Flattening is the less misleading choice. If lap structure is what you need, keep the TCX; most platforms will let you re-split an uploaded activity manually, though the per-lap heart-rate averages are gone regardless.

A Trackpoint with no `<Position>` cannot become a `<trkpt>` and is discarded. This is the normal explanation for a GPX with fewer points than the TCX had: watches sample once a second whether or not there is satellite lock, so a session beginning in a car park, passing through an underpass or running between tall buildings contains stretches of perfectly valid trackpoints carrying a time and a heart rate and no coordinates.

At the extreme, an indoor session — treadmill, turbo trainer, rowing machine — has no positions anywhere in the file, and the conversion reports that no track or waypoints were found. That is accurate rather than a failure: there is no route in the file, and the GPX that would represent it does not exist. For those sessions the training data was the entire content, and converting away from the format that holds it makes no sense in any direction.

A TCX activity has no name element. What it has is a `Sport` attribute restricted by the schema to a short list, and that value becomes the `<name>` of the GPX track — so most converted files come out with a track called `Running`, `Biking` or `Other`.

The title you see in Garmin Connect or Strava lives in that platform's database and is not part of the export, so it cannot be carried. When you are converting several sessions, the practical consequence is that the tracks are indistinguishable by name and you are relying on filenames and on the first timestamp to tell them apart. Renaming the `<name>` element afterwards is a one-line edit in a text editor and worth doing before the files go into a route library.

TCX is the most verbose format in this family. Each trackpoint wraps its coordinates in a `<Position>` element with `<LatitudeDegrees>` and `<LongitudeDegrees>` children, which is 34 characters of tag names before a single digit of data. Measured on a 7,200-point track carrying time and altitude and no sensor data, the TCX came to about 2.2 MB and the equivalent GPX to about 950 KB — roughly 315 bytes a point against 132.

A real Garmin export is larger still, because the heart rate, cadence and distance elements this comparison omits are present on every point. So the shrink you see in practice is usually more than a factor of two, and essentially all of it is the training data leaving. Reading the size drop as efficiency is the wrong conclusion: it is a fairly direct measure of what the file no longer contains.

A TCX can hold several activities in one document, which is how a bulk export from a training platform arrives. Each `<Activity>` becomes its own `<trk>` in the GPX, with its own name taken from its sport, and the tracks appear in document order.

Whether the destination handles that gracefully varies. Route planners generally show a list and let you pick; upload forms that expect one activity per file will often take the first and drop the rest without saying so. If a bulk export has to become individual sessions, split the TCX before converting rather than after — the activity boundaries are obvious in the XML and disappear into track boundaries once the file is a GPX.

Parsing the TCX and writing the GPX both happen locally. No request carries the file anywhere, which the network panel will confirm during a conversion, and the page keeps working with the connection off once it has loaded.

A training file is health data and location data in the same document: heart rate against time, position against time, for the whole of a session that probably started at home. Converters that upload usually keep the file long enough to convert it and sometimes rather longer, and the terms saying which are not what anyone reads at the moment they need a GPX. Doing it in the browser makes the question unnecessary rather than answering it.