Why does distance look different when you open a GPX file somewhere else?

The short answer

A GPX file is a sequence of trackpoints, each one a latitude and longitude with an optional altitude and timestamp attached. Distance is never one of those stored values. Every program that reports a distance for a track — including the app that recorded it — is computing that number itself, by walking through the points in order and summing the straight-line distance between each consecutive pair. Two programs doing that same sum over the same points can land on slightly different totals depending on exactly how each one handles the points along the way, which is the entire explanation for why the number moves when a file changes hands.

What a GPX file actually stores

Open a GPX file in a text editor and what is there is a list of points, each one tagged with latitude, longitude, and usually elevation and time. That is close to the whole of it. There is no running odometer written into the file, no pace curve, no flag marking which stretches were walking versus standing still. Anything beyond raw position — distance, pace, moving time, elevation gain — is something a piece of software works out afterward by looking at the points, not something the format carries as a stored value alongside them.

That is a deliberate limit of the format rather than an oversight. GPX describes where a device was at a series of moments, and leaves every downstream interpretation of that path — how far, how fast, how much climbing — to whatever opens the file next.

Why two programs can add the same points up differently

Summing straight-line distances between consecutive points sounds like it should give one right answer, and for a perfectly clean set of points it would. Real GPS tracks are not perfectly clean. A handful of points in any recorded track sit slightly off from where the phone actually was, and how a piece of software handles those handful of points changes the total. Some programs sum every point exactly as recorded. Others quietly discard or smooth out points that look like noise — an isolated jump too large to be a real step, for instance — before doing the sum. Neither approach is more correct than the other in an absolute sense; they are different judgment calls applied to the same ambiguous data, and different judgment calls produce different totals.

The app that originally recorded the hike often has information available to it in the moment that never makes it into the exported file at all — a live accuracy estimate for each fix, or the device's own sense of whether it was moving, both of which can help decide whether a given point looks trustworthy. None of that supporting context is part of the GPX format, so once the file is exported, a second program is working from the bare points alone, without whatever filtering the original recording was able to apply in real time. That gap in available information, not an error on either side, is the main reason the two totals do not match exactly.

What makes the gap bigger than expected

A difference of a small fraction of the total distance is ordinary and not worth chasing down — it reflects the routine, small disagreements described above. A gap that is large and obvious usually traces back to one specific thing: a small number of points in the file that sit noticeably off the real path, often from the moments right after recording started, a brief loss of signal, or a stretch under heavy tree cover. A program that sums every point without question will add the full, exaggerated distance of that one bad jump straight into the total, while a program that filters outliers first will not. The points themselves are identical in both cases; only the choice of what to do with the outlier differs.

Does the same thing happen with a CSV export?

Yes, for the same underlying reason. A CSV export is still just a table of recorded points, one row per fix, not a stored distance total. Opening it in a spreadsheet and summing distances between rows is exactly the same kind of after-the-fact calculation as opening a GPX file elsewhere, with the same room for the total to land a little differently depending on how the summing is done.

Things that trip people up

• Assuming the GPX export is broken because the number changed after opening it elsewhere — the file usually opened correctly; the two programs simply calculated distance from the raw points independently.
• Treating whichever number is bigger as the "wrong" one — bigger is not automatically less accurate, since it can just as easily mean one program left an outlier point in that the other quietly dropped.
• Expecting an export to carry the original app's live distance total along with it — GPX and CSV both store points, not a finished distance figure, so there is nothing in the file for a second program to simply read off.
• Chasing a difference of a few percent as if it were a bug — that scale of gap is the normal cost of two different programs each making their own small judgment calls about the same imperfect points.

Where TrailCam fits in

TrailCam exports a route as GPX 1.1, the format Strava, Garmin Connect and Komoot read, or as CSV, both part of the optional TrailCam Pro upgrade. Either export carries the recorded points themselves — position, elevation and time — rather than a finished distance number, so whatever the file is opened in afterward will compute its own total the same way any other program would. TrailCam is free to download.