My .fit file shows 255 or 65535 — what those numbers mean
A heart rate of 255, a cadence of 65535, an altitude at four billion — these are not readings. FIT has a specific way of saying “nothing here”, and it looks like a number.
Open your file
Drop your file here
a .fit file from a watch or bike computer
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.
Every FIT type has an “invalid” value
FIT does not use a null. Each field type reserves its top value to mean absent: an 8-bit field is invalid at 255, a 16-bit field at 65535, a 32-bit field at 4294967295. So a heart-rate field showing 255 is the file saying “no heart rate at this record”, not a reading — and a chart that plots it draws a wild spike where there was only a gap. A correct reader turns these sentinels into an explicit missing value.
Signed types and zero are traps too
The rule shifts by type. A signed 8-bit field is invalid at 127, not 255, and some FIT types additionally treat 0 as invalid — so a naive “0xFF means absent” check is wrong for exactly the fields where it matters. This is why some importers show a scattering of zeros that were never measured, and why getting the sentinel right per type is the difference between a gap and a fake reading.
See which of your values are real
This page reads your file on your device and treats every type’s invalid sentinel as missing, so what you see is the data that was actually recorded — no 255-beat heart rates, no four-billion-metre altitudes. It runs locally and uploads nothing.
If this was not your problem, the four things that actually break a .fit file covers the rest, and the file reader opens any file whatever is wrong with it.