A .fit file that Garmin Connect refuses usually still holds the entire ride. The bytes are there; a parser just stops reading them. Understanding which of the three failure modes you have makes the difference between recovering the activity and losing it.
The three things that break
1. A truncated file. The battery died, the memory card filled up, or a transfer was interrupted. The FIT header's byte 4-7 is a 32-bit length field; if it claims more bytes than the file actually contains, a strict parser gives up on message one. This is by far the most common case and the easiest to fix.
2. A CRC mismatch. FIT carries two checksums: a 2-byte header CRC covering the 12 header bytes, and a 2-byte trailing CRC covering everything before it. Either one being wrong is enough for rejection, even when every record message is byte-perfect.
3. A broken definition. Records reference a definition message (field layout) that is missing or corrupt. Recovery then has to resynchronise on the next valid definition.
What repairing actually means
There is no magic here. Repair is mechanical:
- Read the 14-byte header, verify the signature byte is
.(0x2E) and the protocol version is sane. - Recompose the data-length field to match the real file size.
- Recompute the header CRC over the first 12 bytes.
- Walk the definition/record messages until the bytes run out, keeping the last complete message and dropping the partial tail.
- Recompute the trailing file CRC over everything before it.
On a real 700 KB activity file deliberately truncated to 90%, that recovered 11,667 record messages and dropped 11 unreadable bytes — a full 5-hour ride with heart rate intact, from a file that Garmin Connect rejected outright.
Why you should not just "open it in a hex editor"
The header length field is little-endian, the CRCs are CRC-16 with a specific table, and skipping the CRC recomputation leaves you with a file that still fails validation. Get any of those wrong and you produce a file that looks repaired but parses to garbage — which is worse than the original, because now you might not notice the data loss.
Doing it without uploading
Every online repair service asks you to upload the file first. That is a strange trade for GPS data: the file is a precise log of where you live, when you train, and how hard your heart was working.
GPX Converter's FIT repair runs the whole process in a Web Worker in your browser. Drop the file, it reports exactly what it changed (header CRC rewritten, data length corrected, file CRC recomputed, N messages kept, N bytes dropped), and hands back a standards-compliant FIT file. Nothing is uploaded — you can confirm in the devtools network tab.
Once repaired, the same toolbox can convert it to GPX or TCX, merge it with the session before it, split it into segments, or just view the track on a map.
When to give up
If the file is truncated so far that it no longer contains any record messages with GPS positions, no repair will invent them. If a flash failure zeroed a whole middle region rather than cutting the tail, the definition messages are gone and recovery becomes guesswork. In both cases the honest answer is that the activity is lost — a good repair tool should say so rather than hand you an empty track.
