Why do two apps show different pace for the same hike?

The short answer

Pace is distance divided by moving time, worked out after a hike is over rather than read off a sensor while it happens. Nothing about that calculation is measured directly — both of its ingredients are themselves numbers that different apps can already disagree on, for reasons that have nothing to do with pace. So when two apps show a different pace for the same walk, the honest first move is to stop looking at pace at all and check the two numbers underneath it instead.

Pace is arithmetic, not a reading

A GPX track point carries a coordinate, usually an elevation, and a timestamp. There is no field in the format for pace, and no field for moving time either — an app has to work both out from the raw sequence of points every time it opens a file, using whatever distance calculation and whatever stopped-versus-moving rule it happens to use for every other file it opens. That means pace is recomputed from scratch by each app, not carried across from one to the next, so it never had a single "correct" value to preserve in the first place.

When distance disagrees, pace disagrees by the same amount

Two apps rarely land on exactly the same distance for one recorded walk, because distance itself is a sum built from a string of GPS points, and different apps simplify, smooth, or leave that string alone by different amounts. A distance that comes out a few percent higher in one app pushes pace by roughly that same few percent, since distance sits directly on top of the pace fraction. A hike that measures 14.1 kilometres in one app and 14.6 in another will show a proportionally faster or slower pace in whichever app reported the shorter distance, even if both apps agree on moving time down to the second.

When moving time disagrees, the pace gap is usually the bigger one

Moving time is a judgment call, not a fact read off a clock — it depends on which stretches of a walk each app decided counted as stopped. One app might watch GPS speed and subtract anything under a small threshold automatically; another might trust only a pause button pressed by hand; a service you upload a file to afterward may ignore whatever moving time the recording app worked out and recalculate its own from the raw points. Those decisions can disagree by minutes on an ordinary hike, and because pace divides by moving time rather than adding to it, a moving-time gap that looks modest on its own can move the pace figure by more than a similarly sized distance gap does. Most real pace disagreements between two apps trace back to this rather than to distance.

Rounding and display add a small gap of their own

Even when distance and moving time land close enough that they should not matter, pace can still come out looking different once it reaches the screen. Pace is usually shown rounded to the nearest few seconds per kilometre or mile, and rounding a ratio built from two already-slightly-different numbers can nudge the displayed figure by a notch even when the underlying difference is tiny. Switching between kilometres and miles adds a conversion step that rounds again. None of this is the same kind of gap as a real disagreement in distance or moving time — it is closer to reading the same number off two rulers with slightly different tick marks.

Why the two causes rarely cancel each other out

It is tempting to assume that an app running slightly long on distance and slightly long on moving time would cancel out in the final pace, since both sit on opposite sides of the same division. In practice there is no reason for the two to move together, because each app calculates distance and moving time independently, using rules built for entirely different problems — one is about summing GPS wobble, the other is about detecting stops. Sometimes the two errors partly offset by coincidence, sometimes they stack in the same direction, and there is no way to tell which happened just by looking at the final pace gap. Checking distance and moving time separately is the only way to see what is actually going on underneath.

Things that trip people up

• Assuming a pace mismatch points to a bug in one of the apps — it is almost always two upstream numbers disagreeing, not a fault in how pace itself gets calculated.
• Comparing pace between two apps without first checking whether their distance and moving time individually match — a pace gap with both of those aligned is usually just rounding.
• Confusing this with the gap between current pace and average pace inside a single app — that is a live snapshot versus a whole-walk summary, a different question from why two different apps disagree about the same finished hike.
• Expecting a re-imported GPX file to carry over the pace an app originally calculated — the file never stored one, so the importing app is working it out fresh from distance and moving time it has also just recalculated.

Where TrailCam fits in

TrailCam reports pace per kilometre or mile for every route, built from a distance and a moving time that come from the same recording rather than being recalculated twice by two different services — moving time comes from a pause button you press yourself, not a guess at your GPS speed. A route exports as GPX 1.1 or CSV, and the CSV summary keeps distance, moving time and pace together, so the figures travel with the hike instead of being rebuilt from scratch by whatever opens the file next. Export is part of the optional TrailCam Pro upgrade; the app itself is free to download.