A truncated .fit file — recovering a ride that ended early

A truncated file is not an empty one. Drop it below and you will get everything that was written before the cut, plus a note saying where it stopped.

Open your file

Drop your file here

the .fit file that ends early

No account. No upload. The file is read on this device and never leaves it.

Nothing has been sent anywhere. 0 requests to this site, for the page's own code.

What truncation looks like inside the file

A FIT header declares a data_size: the number of bytes of records that follow it. The device writes that number when it starts the file, based on what it intends to write. If the activity ends unexpectedly — flat battery, storage full, the cable pulled mid-transfer — the file stops short of what the header promised.

Nothing about the records already written is damaged. FIT is a streaming format: each record is complete when it is written. What is missing is whatever came after, which for an activity is usually the session and lap summaries the device writes at the end.

Why that matters more than it should

Those trailing summaries are where a lot of software looks first — total distance, average heart rate, elapsed time. A file without them can open, show a blank summary, and give the impression that nothing is there, even though every second of the ride is present in the record messages.

The tool above counts the record messages directly, so a truncated activity shows its real extent rather than an empty summary.

How much you keep

Everything up to the cut. In practice that means a ride that ended at 2h47 gives you 2h47 of data and no totals. Our own corpus contains 4 files that stop early out of 68,068, and the parser recovers what precedes the cut in every one of them — the worst of them still yields 143,973 data points despite being unreadable to a strict parser.

Getting a file other tools will accept

You have three options, in order of how much they preserve:

  1. Re-sync from the device. If the watch still holds the activity, the copy on it may be complete — the truncation may have happened during transfer rather than during recording.
  2. Export from the vendor's service. If it uploaded before the failure, the service has a complete copy and will re-export it.
  3. Use the data as-is. Download the summary here to confirm what survived, then import into whatever accepts partial files.

What we would not do is pad the file to match its header. That produces a file which passes a length check and contains invented bytes, which is worse than an honestly short one.