How to Fix a Corrupt FIT File (and Why FIT Files Break)
The ride is in the watch. You can see it in the history: time, miles, the works. But the file will not load — not in the app, not on the site, not anywhere. The word for this is corrupt, and it sounds final. Most of the time it is not. A FIT file is a strict form, and strict forms break in a small set of known ways.
FIT is the binary format that Garmin gear and most bike computers write. It is compact and rich: each second of your ride is a record, and the file ends with a session record and a checksum that proves the file is whole. When any part of that chain snaps, strict readers refuse the whole file — even when 99% of your ride sits inside, intact.
This guide names the five faults that cause most corrupt FIT files, shows what a repair can and cannot save, and walks through a sound repair flow: diagnose first, fix the fault, then read the report like a skeptic. The goal is a file that platforms accept and that still tells the truth about your ride.
A note on scope: repair works on files that broke in the ways below. It cannot bring back data a device never wrote. If your file was rejected at upload but might be whole, start with the fault hunt in why a Garmin activity won't upload — and how to fix the file. If you know the file is broken, read on.
What “corrupt” means for a FIT file
A FIT file is a chain. At the head, a short block says what kind of file it is and how long it runs. Then come the records: a stream of points, laps, and events, each in a set binary shape. At the tail sit the session and activity records — the totals — and a two-byte checksum, the CRC, worked out from every byte before it.
Readers check the chain before they trust the data. Wrong length at the head, a record that ends mid-byte, totals that do not match the points, a checksum that fails — any one of these can make a reader stop. That strictness is a feature when files are whole. It is a wall when a file broke by one link.
Corrupt, then, does not mean the data is mush. It means the chain failed a check. Your ride's points are most often fine. The job of repair is to find the snapped link, fix the form around the data that lives, and rebuild the tail so readers trust the file again.
The five ways FIT files break
Nearly every broken FIT file we see broke in one of these five ways. The table is the short form; the text below it is what to do with it.
| Fault | Usual cause | Sign | Can repair save it? |
|---|---|---|---|
| Cut tail | Battery died or unit froze mid-ride | File ends with no session record | Yes — points up to the cut are kept |
| Bad checksum | A byte flipped in storage or sync | Reader reports a CRC error | Yes — data is whole, the proof is rebuilt |
| Missing ending | Save was stopped before the tail was wrote | Loads in loose tools, fails in strict ones | Yes — the ending is rebuilt from the points |
| Broken time stamps | Clock fault, dead backup cell, bad edit | Times jump years or run backwards | Often — if the true order can be rebuilt |
| Cut mid-record | File was copied while still being wrote | Last record is half a record | Yes — the half record is dropped, the rest kept |
Note the one that is not on the list: a ride that was never saved at all. If the device shows no history entry, there is no file, and no tool can fix an absence. The five faults above all leave a file on disk — that file is your raw ore.
Which fault you have shapes what to do next, so take a breath before you click anything. A clean cut (truncation) is the best news: the data is all there up to the cut, and a repair is near-whole. A lied length or a stale total is clerical: the ride is whole and the fix is small. Bit rot inside the data is the hard case: some span of the ride is gone in a way no tool can undo, and the honest aim is to save the rest. Name the fault first. The tool's next step follows from the name.
One thing not to do: do not “fix” the file by opening it in a text editor and trimming lines. FIT is binary. A text editor will mangle bytes it cannot show, and a bad file becomes an unreadable one. If you want a look inside, use a reader that parses the form and shows you records. Eyes are fine. Hands off the raw bytes.
What a repair can save — and what it cannot
A sound repair keeps every whole record in the file. For a cut tail, that is the whole ride up to the second the device died — often all but the last few minutes of a long ride. The repair drops the half record at the cut, rebuilds the session and activity tail from the points that live, and writes a fresh checksum. The result is a whole file about a slightly shorter ride — the true ride, minus its lost tail.
What repair cannot do is just as plain. It cannot invent points the device never wrote. It cannot fix a heart rate stream that was junk at the source. And it should not “fix” totals by making them up: honest totals are counted from the kept points, even when that makes the ride look shorter than the one you set out to do. A repair tool that hides what it dropped is a tool that will lie to you again.
Step by step: diagnose first, then repair
In FitMerge, upload the broken file and read the health check first. It names the fault in plain words — cut tail, bad checksum, missing ending — and counts the points that can be kept. Only then run the repair. The output is a rebuilt FIT file plus a repair report. That order is the whole method: know what is wrong before you let a tool touch it.
Why insist on the diagnosis? Because the right fix flows from the fault. A bad checksum with whole data wants a rebuilt proof and no lost points. A cut tail wants a rebuilt ending and an honest shorter total. A tool that applies one blind fix to all files will, sooner or later, throw away data it could have kept — or keep data it should have flagged.
After the repair, test the output the way a skeptic would. Load it in a second tool. Check that the point count in the report matches what the tool shows. Look at the map. Then upload it. If it will join a second file from the same ride, do the repair first and the merge second — the merge modes are in how to combine FIT files from two devices.
Keep the damaged file through the whole job — do not let any tool overwrite it in place. Work on a copy, save the repair under a new name, and only delete the broken raw file when the repaired one has passed its checks and posted where it needs to post. Storage is cheap. The start-line data of a race is not.
How long does a repair take? The scan is fast — even a long file parses in seconds. Your time goes on the checks after: span, points, streams. Plan on five minutes, most of it reading. That is a fair trade for a file the platform swore was dead.
How to read a repair report
A repair report should read like a shop bill: each fault found, each fix made, each loss owned. Look for four lines. The fault list — what was wrong, in words you can check. The kept count — how many points and how much time the output holds. The dropped count — what was cut and why. And the rebuilt parts — which tail records and totals were made fresh from the kept points.
Hold the report up against the file. If the report says 5,000 points were kept, a reader should count near 5,000 records in the output. If the totals in the session record match a count of the points, the rebuild was honest. This is the same habit we teach for merges in how to check merged totals, points, and coverage — numbers you can re-count beat claims you must trust.
A report with no losses on a cut-tail file is a red flag. So is a report that will not name the fault. Repair is a trust trade: the tool shows its work, you grant the file a place in your log. Keep the raw broken file and the report with the fixed one. If a platform ever asks what changed, you hold the full story.
A report line that says “X points dropped” should always come with a place: where in the ride the loss sits. A drop at the very end — the walk back to the car — costs little. A drop at the race's key climb costs the story. If the report does not say where, ask the map: the repaired track will show a straight line or a gap at the lost span. Judge the repair by where the loss sits, not just by how large it is.
And if two tools give two counts for the same repaired file, trust the stricter reader. A lax reader skips bad blocks in silence and reports a whole file. A strict one halts or flags. For a file you plan to trust, strict is the friend. It is the same rule as for merges: believe the count you can re-check.
Habits that keep files from breaking
Most breaks trace back to power or to haste. Let the device finish its save before you pull the cable or close the app — a file copied while it is being wrote is a cut file by hand. Keep the battery off the edge on long rides; a unit that dies at hour five writes the most costly cut tail of all. Update the device's own code when the maker ships fixes; save faults are a known class of bug.
Sync by one path, not three. A file that passes through a phone app, a cloud drive, and a cable has three chances to be cut short. Pull the raw file from the device when you can, and keep the raw set for each ride in a folder of its own. When you do need a different form of a sound file, convert it — do not hand-edit binary. The forms and their safe paths are in the next guide if you want them.
And when a file does break, act while the ride is fresh in mind. You will know if the output is short a climb or a loop. A week later, the report is all you have — which is one more reason to pick tools that write one. Read FIT vs GPX vs TCX: which format keeps your data for where each form is strong and where each one snaps.
The short version
Corrupt means the chain broke, not that the ride is gone. Diagnose the fault, keep every whole point, rebuild the tail and the proof, and read the report before you trust the file. Run your broken file through the health check — the diagnosis is free, and the repair report lists every fix and every loss.
Sources and further reading
- GPS and Telling Time — GPS.gov — Why GPS clocks are so exact, and how devices use them to stamp each point in time.
- Time and Frequency Division — NIST — The U.S. lab that keeps official time — the root of the clock in every file you merge.
- GPS Accuracy — GPS.gov — The U.S. government's own page on how exact GPS fixes are, and what makes them drift.