Repair a broken activity file
Your file never leaves your device — conversion happens here in your browser.
Every trackpoint in a GPS activity file carries a timestamp, and every tool that reads one — a pace graph, a lap calculator, a map that animates your route over time — assumes those timestamps only ever move forward. When they don't, when a point partway through the file is stamped earlier than the point before it, that assumption breaks: speed calculations go negative or spike absurdly, animated playback jumps backward, and some importers reject the file outright rather than guess at what order you meant. This usually isn't random corruption — it's structural. Merging two overlapping exports, editing a file by hand, or reassembling one from a converter that processed segments independently can all leave you with a file that's internally consistent in every way except that the clock doesn't run one direction. FitFileHub's repair tool checks whether timestamps increase monotonically across the whole file and, if they don't, reorders every point by its actual recorded time — the position, elevation, and sensor data attached to each point move with it, so nothing gets separated from its original reading. It shows you the defect was found before it reorders anything, and a file whose timestamps are already in order is left untouched and reported as fine. This is a distinct defect from a missing timestamp — a point with no time at all isn't out of order, it's absent, and that's fixed by interpolation instead. Both can occur in the same file. Runs entirely in your browser, nothing uploaded. Free up to 25 MB per file, three files at a time.
Questions
What causes timestamps to run backward in a file?
Usually a structural issue rather than random corruption — merging two overlapping exports, hand-editing a file, or reassembling one from segments a converter processed independently and reattached out of sequence.
Does reordering points change my elevation or heart rate data?
No. Position, elevation, and sensor readings attached to each point move with it when the point is reordered — nothing is separated from its original reading.
Is this the same problem as a missing timestamp?
No. A missing timestamp means no time value at all on a point; out-of-order means every point has a time, but the sequence doesn't increase. They're fixed differently, and a file can have both at once.
What happens if my file's timestamps are already in order?
It's reported as fine and left completely untouched — the check never modifies a file that doesn't need it.