FIT file CRC mismatch — what it means and whether your data is lost
A CRC mismatch sounds fatal and almost never is. Drop the file and see how much of it reads — in our corpus, every file that fails its checksum still parses completely.
Open your file
Drop your file here
the .fit file reporting a checksum error
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 the checksum actually covers
A FIT file carries a 16-bit CRC over the header, and another over the file's data section, written at the very end. It is a transport check: it answers "are these bytes exactly the ones the device wrote?" and nothing else.
Critically, it is verified after the records have already been read. By the time a parser can check it, it has the data. A reader that refuses the file on a CRC failure is discarding something it has already successfully decoded — which is why the tool above reports the mismatch and shows you the contents anyway.
How often it happens
3 files out of 68,068. All of them readable. That is the entire empirical basis for treating a CRC failure as a warning rather than an error, and it is more than most FIT readers have.
Why it fails when the data is fine
- The file was edited. Any tool that rewrote the file — to strip GPS, merge two activities, correct a timestamp — and did not recompute the CRC leaves a valid file with a stale checksum. This is the commonest cause by far.
- It was truncated. The data CRC lives at the end of the file. If the file was cut short, the checksum is simply not there, and some readers report that as a mismatch. See truncated files.
- A trailing byte was added. Some transfer paths pad files. The content is untouched; the checksum no longer covers what follows it.
- Genuine bit rot. Real, and rare. It shows up as implausible values, not as a clean file with a bad number at the end.
What to do
- Open it with something that does not refuse on CRC — the tool above, for instance.
- Check the record count and date range against what you expect from that activity.
- If the record counts look right, the data is almost certainly fine.
- If you need a file other tools will accept, re-export it from the device or service rather than patching the checksum.