GPSBabel is the converter that sits between every GPS format you own

A converter with a common internal format

The project describes itself simply. This is the source code for GPSBabel, the free software project to manage GPS data, meaning waypoints, tracks and routes, in your GPSes or in related programs.

The description at the repository level is wider still: convert, manipulate, and transfer data from GPS programs or GPS receivers, open source and supported on macOS, Windows, Linux and more, with a pointy clicky GUI or a command line version.

The word manipulate is the one that distinguishes it from a simple translator. A converter takes format A and produces format B. A manipulator also takes a track and shortens it, removes duplicates, smooths the path, splits it at a distance, applies a style file, or filters out the parts you do not want. Both are in the same tool because both are operations on the same internal representation.

That representation is the design. The repository layout shows it directly: there is a format.h and a filter.h, a format_skeleton.cc and a filter_vecs.cc, and a long list of small paired source files, each with its own .cc and .h. The format handlers are the things that read and write a particular file type, and the filters are the things that transform data between formats.

So the pipeline is: read a file in one format into the common internal model, apply zero or more filters to it, write it out in another format. Adding support for a new format means writing one handler, not one converter per pair. That is why the repository can cover a lot of formats without becoming a matrix of combinations, and it is the reason a tool that started in the era of serial GPS receivers is still usable with modern devices.

The project is C++, GPL-2.0 licensed, with the default branch master, the homepage at gpsbabel.org and the last push on 2026-10-20.

The format list is the real feature list

The file names at the top of the repository are a directory of the formats covered, and it is a long one.

The Garmin family dominates, which is unsurprising given that Garmin is the largest maker of consumer GPS hardware. There is garmin.cc for the binary Garmin format, garmin_fit.cc for the FIT format, garmin_fs.cc for the filesystem that sits on a Garmin unit, garmin_gpi.cc for the GPI format, garmin_txt.cc for the text-based variant, garmin_xt.cc for the XT format, and garmin_icon_tables.h and garmin_tables.cc holding the built-in icon and model tables.

The split between garmin_fs and garmin_gpi is the interesting one. Filesystem formats describe the whole contents of a device, including the waypoints, tracks and configuration stored on it, while the GPI format is just one file within that filesystem. Separating them means you can extract a single file from a device image without unpacking the rest.

Then there are the data loggers. dg-100.cc and dg-388.cc are data logger formats, each handled by its own pair of source files. These are the opposite problem from a GPS track: a fixed-width record per sample rather than a variable-length list of points with timestamps.

And then the generic formats. csv_util.cc and csv_util.h handle delimited text, which is the interchange format that everything else can be converted to and from. exif.cc handles EXIF metadata, which matters because photographs taken on a phone carry a GPS tag and it is often the only way to get location data out of a picture. formspec.cc handles the field specification used by some text formats, where the columns are described rather than fixed.

The supporting files are the infrastructure. defs.h holds the core definitions, gbfile.cc handles the file abstraction that lets the tool work on a device as if it were a directory, and filter_vecs.cc is the registry that knows which filters exist and how to invoke them.

That last point is worth noting. The tool does not hard-code a fixed order of operations. It has a registry of available filters, and the command line selects which ones run and in what order.

The filters are the operations you would otherwise script

The filter files are where the processing lives, and their names describe a working GPS data toolkit.

arcdist.cc is arc distance, which is the problem of computing how far along a track you have travelled when the track is made of segments rather than straight lines. That is the number you need for a progress bar, a distance-to-goal readout, or any split. It is a small computation that is easy to get subtly wrong, and having it in one place is the value.

bend.cc handles bending, which is the smoothing of sharp corners in a track. It is what turns a jagged line of GPS samples into a plausible path, and it is a filter rather than a format concern because the same smoothing is useful on tracks coming from any source.

duplicate.cc removes duplicate points, and discard.cc removes points, which together handle the two ways a track accumulates junk. A receiver sitting still emits many identical positions, and a track stitched together from several files has the junctions repeated. Both filters exist because the alternative is writing the same cleanup code in whatever tool you happen to be using.

Then there are the metadata and output-shaping filters. exif.cc, as mentioned, is about EXIF. The Garmin table files and the icon tables belong to the format side but carry the same idea: device-specific knowledge is data, not code, where it can be.

The architecture that emerges is a tool where the file formats are interchangeable at the edges and the interesting operations live in the middle. You can read a track from a Fit file off a watch, apply duplicate removal and arc distance, and write the result as CSV, without any of those steps knowing about the others.

The form and style of the filter interface also follows from the registry design. Since filters are looked up by name and can be applied in a chosen order, the same set of operations composes into a pipeline, and the ordering matters in ways you control. Applying duplicate removal after smoothing gives a different result than the other way round.

Two front ends, one engine

The repository description offers both a pointy clicky GUI and a command line version, and the topic tags include qt and qt-gui, which identifies the GUI toolkit.

That split is the practical shape of most desktop tools of this kind, and it reflects two quite different users. The command line version is for people with data files, scripts and pipelines, who want to run the same conversion over a directory of files and check the result in a diff. The GUI is for people who have a device and want to see what is on it before deciding what to do with it.

Having both over the same engine is what makes that split work. The GUI is not a separate implementation with its own logic, it is a front end over the same filter pipeline, so a conversion done in one behaves identically to the same conversion in the other.

The build system is CMake, with a CMakeLists.txt at the root. The per-format sources listed at the top of the repository are the visible part of the build, and a project with this many formats usually makes each one conditional at the configure stage, so you build only the support you need.

There is also a style configuration file, astylerc, which tells the project which automatic formatter to apply and with what settings. For a C++ codebase with a large number of contributors, agreeing on formatting by tool rather than by review is the difference between a mechanical change and an argument.

And there is a coverity_model.cc at the top level, which is the model file used by the Coverity static analysis service, alongside a SECURITY.md and an AUTHORS file.

The scale of the codebase is worth noting as context. The visible portion of the repository root already contains a long run of source files with matching headers, and that is only the first alphabetic run of the tree.

Continuous builds across five platforms

The build status badges at the top of the documentation cover five separate checks, and the release tags show how they are used.

There is CodeQL for the security analysis, and then four platform builds: Fedora, macOS, ubuntu and windows. Each has its own workflow file in the .github directory, which means the project tests on four operating systems rather than one.

The comment above them is a small piece of tone that says something about the culture. Passing is good. We like passing.

The recent releases are named after that: Continuous-macOS, Continuous-Windows and Continuous-Linux, all tagged on the same day, each described as a continuous build. The tag names literally state which platform they cover, which is the convention a multi-platform project needs when the master branch produces several distinct artefacts.

That is a notable amount of automation for a project whose own documentation says the latest official release is available as a separate download. The continuous builds are for the master branch and exist to catch breakage early; the official release is the stable artefact that users download from the project's site.

The Codacy badge is also there, and the project is explicitly proud of the rating, which is a small indicator of how the project presents its quality record.

For a converter of this kind, cross-platform correctness is not a nicety. The formats themselves are full of platform assumptions: byte order, struct packing, line endings, character encodings for waypoint names, and filesystems with different constraints on what a filename can look like. A tool that reads a track off a device on one system and writes it out on another has to get those right every time, and running the tests on four platforms is how you find out.

A project that asks for more than code

The contributor section is unusually broad about what it needs, and that is worth reading as a statement of what makes a project like this hard to sustain.

The first line welcomes new open source contributors, and there is a contributor guide in the repository at README.contrib, along with a pull requests welcome badge and a link to makeapullrequest.com.

Then comes the part that is rarely said this plainly. If you aren't a programmer or a writer, we need help with gear, hosting costs, tool license prices, answering questions on the mailing lists, etc. Please support GPSBabel any way you can.

For a project that has existed for decades and supports a huge number of obscure hardware formats, that list is not filler. The domain knowledge is the asset. Someone who has used a particular GPS device for fifteen years knows what its files look like and what the real-world bugs are, and that person is more valuable to the project than another patch.

The same applies to the other items. Tool license prices matter for a project that has to run static analysis and continuous integration across several platforms. Hosting costs matter for a project serving binaries. Answering questions on the mailing lists is the work of the people who have absorbed the accumulated knowledge of the formats and are the only ones who can pass it on.

The AUTHORS file at the repository root and the CHIEF Babel-Head attribution to @robertlipe point at how the project has been organised. That handle is a joke about the Tower of Babel and the many file formats, but it also names the person who has run the project for a long time, and the continuity of that role is a fact about how open source projects of this age are usually sustained.

The last push was on 2026-10-20, the continuous builds for macOS, Windows and Linux are from the same day, and the project is GPL-2.0 licensed with the COPYING file at the root.

Editorial conclusion

Adopt GPSBabel if you have GPS data spread across several formats or devices and need to move, split or reshape it, since the common internal format and the filter model are what make that practical. Skip it if you only need to read one format into one application, since a single library will do. Verify first which formats you actually need, since each is a separate module in the build, that you read the contributor guide before submitting patches, since the project has its own conventions, and how you want the work driven, since the command line version and the Qt front end cover different use cases.

Frequently asked questions

Official sources

1. GPSBabel/gpsbabel on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases