It is becoming increasingly common for bicyclists to record their rides using cycling computers and watches, the majority of which save the data they collect using the Flexible and Interoperable Data Transfer (.FIT) Protocol. As the contents of .FIT files are not readily accessible to users, the purpose of this paper is to demonstrate the differences induced by several common methods of analyzing .FIT files. We used a Garmin Edge 840 bicycle computer with a wireless wheel speed sensor to record ride data at both 1 Hz frequency and using the computer’s Smart Recording setting. The.FIT files were downloaded directly from the computer, uploaded to the test platforms, and then exported to .GPX, and/or .CSV formats: the platforms tested were Strava, RideWithGPS, Garmin Connect, and GoldenCheetah. Those same .FIT files were also converted directly to .CSV using the Garmin FIT Software Developer Kit (SDK) FitCSVTool utility, written to .KML files using a custom MATLAB script, and compared to the files produced by the test platforms. First, when imported into Google Maps, the latitude, longitude, and timestamp data from the .GPX files exactly matched the directly converted data; however, the speed data all appeared to be calculated by backwards differentiation of the GPS data, while the directly converted speeds were measured from the wheel speed sensor. Additionally, all the test files maintained the same number of data points as the directly converted file except for Golden Cheetah: in both the exported .CSV and .GPX files, Golden Cheetah interpolated times and positions for missing data points to artificially produce 1 Hz resolution. Lastly, the directly translated CSV file contained significantly more data than any of the other exported files did - connected ANT+ and Bluetooth devices, hardware product model, and software version, and more - all of which could be important to an analyst reconstructing an incident.