Convert GPX to CSV

A GPX file is nested XML. A `<trk>` element holds one or more `<trkseg>` elements, each of which holds a long list of `<trkpt>` elements that carry latitude and longitude as attributes and elevation and time as children. A spreadsheet has no way to express that nesting, so the conversion flattens it: every trackpoint becomes one row, in the order the recorder wrote it, and the structure above the point survives only as two columns saying what kind of thing the row came from and what it was called.

That flattening is the whole trade. You gain a table you can sort, filter, chart and hand to pandas; you lose the ability to reassemble the original GPX with its grouping intact. Keep the GPX if the round trip matters. If the analysis matters, the table is the better object — a two-hour ride recorded once a second is 7,200 rows, which any spreadsheet opens without complaint and any dataframe reads in a few milliseconds.

The header row is `type,name,latitude,longitude,elevation,time` and there is no seventh column. `type` is either `track` or `waypoint`. `name` is the name of the track or of the waypoint the row belongs to, repeated on every row so a filter on one track works without a lookup. `latitude` and `longitude` are decimal degrees, elevation is metres above sea level as the GPX stated it, and `time` is the timestamp exactly as recorded.

Speed, distance, gradient and pace are deliberately absent, even though a converter could compute all four. Each of them requires a smoothing decision — over how many samples, discarding which outliers — and a value invented by that decision looks identical in a spreadsheet to one that was measured. Distance between consecutive rows is one line of arithmetic once the table is in front of you, and then the choice is yours and visible.

A GPX splits a track into segments wherever the recorder lost its fix, and those `<trkseg>` boundaries are dropped: the points come out as one continuous run of rows, so a ride through a long tunnel is not silently cut into two datasets. If you need to find those gaps again, they are visible in the `time` column as a jump between consecutive rows.

Routes are handled the same way. A `<rte>` element is a planned line rather than a recorded one, and its points appear typed as `track`, because in a table there is nothing else they could honestly be. Waypoints are different and come out first, typed `waypoint`, each keeping the name it had. A GPX holding one track and twelve saved points gives you twelve waypoint rows followed by the trackpoints, separable with a filter on the first column.

Most watches record more than position. Heart rate, cadence, temperature and power go into an `<extensions>` block inside each `<trkpt>`, usually under Garmin's TrackPointExtension namespace. The reader here takes latitude, longitude, `<ele>` and `<time>` and stops, so none of those values appear in the CSV and no column is created for them.

This is worth knowing before you plan an analysis around them, because the output looks complete. If sensor streams are what you actually want, no conversion on this site will hand them to you in a table — the TCX route has the same limitation for the same reason. The honest advice is to parse the extensions block yourself, or to export the workout from the platform that recorded it, which usually offers a CSV with those columns already.

Latitude and longitude are written with exactly six digits after the point, which is about 11 centimetres at the equator. That is not a round number chosen for tidiness. A consumer GPS receiver has a position error of several metres in the open and considerably worse under trees or between buildings, so a seventh and eighth decimal describe the receiver rather than the ground.

The consequence is that a GPX whose points were stored with the full precision a double can hold comes back rounded, and a comparison against the source will show differences in the eighth decimal. For a recorded consumer track that is a rounding of noise. For survey data it would be a loss, and survey data is not what this conversion is for — a total-station export belongs in a GIS tool that keeps its own precision model.

Elevation is copied exactly as the GPX wrote it, with no rounding and no unit conversion: the specification says metres above the WGS 84 ellipsoid, so `512.4` in the file is `512.4` in the cell. Timestamps are copied verbatim too. ISO 8601 is already a standard and reformatting it would only introduce an opinion, so `2026-05-12T07:03:11Z` stays exactly that and a device that writes milliseconds keeps them.

One useful side effect: ISO 8601 sorts correctly as plain text, so ordering the table by the `time` column works even in a tool that has not recognised it as a date. The matching gotcha is that a point without a timestamp leaves the cell empty rather than filling it with a zero or an epoch, and mixed exports do occur — a track logged with time next to waypoints marked by hand, which carry none.

Two things go wrong when a coordinate table is opened by double-clicking it. In a locale configured for a comma decimal separator, `48.137154` is read as text rather than as a number, and the whole latitude column arrives left-aligned and useless for charting. And the `time` column is often reinterpreted as a date-time in the local zone, which silently shifts a UTC track by an hour or more.

Both are avoided by importing rather than opening: Excel's text import dialog lets you set the file origin and mark individual columns, and the two coordinate columns want the English number format while the time column is safest left as text. In pandas none of this arises — `read_csv` handles the file directly, and `parse_dates=["time"]` produces timezone-aware timestamps because the offset is already in the string.

XML pays for its structure in bytes. On a synthetic 7,200-point track with elevation and a timestamp on every point — two hours at one sample a second — the GPX is about 950 KB, roughly 132 bytes per point, most of it the repeated `<trkpt>`, `<ele>` and `<time>` tags. The same points as CSV are about 500 KB, near 70 bytes per point, and that is with nothing dropped.

Neither number is large enough to matter on its own, which is the point worth making: there is no size reason to convert. The free ceiling here is 100 MB, and at 132 bytes a point a 100 MB GPX holds something like three-quarters of a million trackpoints, or nine days of continuous one-second recording. Files in that range exist — a season of activities merged into one — and they convert, though the browser tab will want the memory.

Every file converted here has the same six columns in the same order, so combining a folder of them is a matter of dropping the repeated header rows — a `pd.concat` over a glob, or a paste in a spreadsheet. What the combined table lacks is anything recording which file a row came from, because the `name` column carries the track name and a great many exports leave that as a device default or omit it entirely.

Add the filename as an extra column while you are reading each file, which in pandas is one line inside the loop. It is worth doing before the merge rather than after: once fifty thousand rows are in one frame, the only thing distinguishing fourteen rides is the timestamps, and two sessions recorded on the same morning will interleave the moment the table is sorted by time.

The parsing and the writing both run in this tab. No request carries the GPX anywhere, which is checkable in the network panel while a conversion runs, and the conversion works with the connection switched off once the page has loaded. That claim is worth more here than on most pairs.

A GPX is not a document about a subject; it is a list of the exact places you were and the exact minutes you were there. The first and last point of a ride is very often a home address, and a resting heart rate at 06:40 says when the house was empty. The CSV is if anything more exposed than the source, because it is legible to anyone who can open a spreadsheet. Store it where you store the GPX.