Free tool

Browse every message and field inside a raw FIT file.

Inspect any Garmin FIT file message by message, field by field, in your browser. Tree-view every record type, search across fields, see timestamps and semicircle positions decoded properly. The deep-dive read-only viewer for anyone debugging a head unit, validating a third-party export, or figuring out why a file refuses to upload to Strava.

0F A3 21 B7becomesrecordMesgs: 8,412

How it works

  1. 1

    Drop a .fit file

    We decode the binary in your browser - the SDK reads every message type Garmin defines.

  2. 2

    Pick a message type

    Tree on the left lists every type with a count. Click one to see every entry as a table on the right.

  3. 3

    Search and skim

    Filter rows by any field value. Timestamps render as ISO, semicircle positions get converted to degrees.

What you get

  • Every message type tree-listed with row counts
  • Semicircle positions auto-converted to lat/lon decimal degrees
  • Timestamps rendered as ISO 8601 instead of raw seconds-since-1989
  • Per-table search filter across all fields
  • Powered by the official Garmin FIT SDK - decodes every standard message
  • Works offline - your FIT stays on your device, never uploaded

When to use this

Open the Inspector whenever you need to know exactly what is in a FIT file. Debugging a head unit that records weird data, validating that a third-party export contains the fields you expect, figuring out why an upload to Strava failed, confirming that a tool ran correctly (drop the before and after files in and diff), checking which sensors were paired during a ride, hunting for proprietary developer fields, or just satisfying curiosity about the binary format your $1000 bike computer writes. It is the closest thing to a debugger you get for FIT files.

How it works under the hood

The tool loads your file into the official Garmin FIT JavaScript SDK in your browser. The SDK parses the binary into a typed object - one array per message type, populated with one entry per occurrence in the file. We hand that object to a virtualised table renderer, with a tree of message-type counts in the sidebar. The lat/lon conversion is a multiplication by (180 / 2^31). The timestamp conversion is an addition of the FIT epoch (631065600 seconds offset from Unix epoch, because FIT counts from 1989-12-31 UTC). Search is a string-contains filter applied across every field value of every visible row. Nothing happens server-side.

Common mistakes

Two common ones. First, expecting the Inspector to surface "errors" - it does not, because the FIT format does not really have errors at the field level. A file is either decodable or not. If you want to know why your activity has wrong stats, look at the session and record messages and compare against what you expect. Second, panicking at the unknown_xxx message types - they are normal. Every modern head unit writes vendor extensions and they do not affect any official platform's reading of the file.

Frequently asked questions

Can I edit anything in the Inspector?
No - this tool is strictly read-only. It is the diagnostic counterpart to the rest of the suite. When you need to change a file, use the other utilities: [FIT Time Adjuster](/tools/fit-time-adjuster) for clock shifts, [FIT Sport Changer](/tools/fit-sport-changer) for sport rewriting, [FIT Device Changer](/tools/fit-device-changer) for device metadata, and so on.
Why are some position values huge integers?
The FIT format stores latitude and longitude as semicircles - a 32-bit signed integer where 2^31 semicircles equals 180 degrees. The raw values look like 535124800 instead of 47.85. We convert any field name ending in _lat or _long to decimal degrees so you see the human-readable coordinate next to the raw int.
Will the Inspector choke on a multi-hour file?
No - the tables virtualise via the browser's native scrolling, so you can click into a record table with 30,000 entries and the UI stays snappy. The decode itself takes about a second per hour of activity on a modern laptop. Files from a long brevet or 24-hour ride open without trouble.
What message types should I look at first?
For an activity file: start with file_id (manufacturer, product, time created), session (the summary record - total distance, total time, averages), lap (per-lap summaries), record (per-second data), and event (start/stop, lap presses, autopause triggers). For a course file: course, course_point (turn prompts), and record. For a workout file: workout and workout_step.
My file fails to decode in another tool. Will this work?
Often yes. We use the official Garmin SDK with strict validation off, so files with minor corruption or non-standard extensions still display what they can. If even the Inspector cannot decode it, the file is genuinely broken and you need a recovery tool - or a fresh export from the source.
How do I find out which device wrote a file?
Open the device_info messages. The manufacturer field is the Garmin enum (or wahoo_fitness, suunto, coros, etc), and the product field is the device model. The first device_info row is usually the head unit or watch itself; later rows are paired sensors (HRM, power meter, cadence sensor, etc).
Why does my file have hundreds of "unknown_xxx" message types?
Garmin reserves space in the FIT spec for vendor-specific extensions, and Wahoo, Stages, Coros, and Polar all use it for proprietary data. The unknown message types are usually private vendor data that Strava and Garmin Connect ignore. They are harmless - they just are not in the public spec.
What is a developer field?
Developer fields are custom fields written into the FIT by a third-party app or Connect IQ data field. They have their own field_description messages declaring their name and units. The Inspector renders both the field_description tables and the developer-field columns inline with the standard fields.

Save your training to a real log

Inspect the bytes, then keep every ride and run analyzed in one place. Domestique reads the data for you.

Create free account