KML vs. GeoJSON vs. GPX: Choosing the Right Map File Format

KML, GeoJSON and GPX overlap, but they were designed for different jobs. KML is strongly associated with Google Earth workflows, GeoJSON is common in web mapping and data exchange, and GPX is widely used for GPS tracks and waypoints. Understanding those strengths helps you choose a format before converting anything.

GeoJSON — a web-mapping favourite

• Plain JSON, which is straightforward to parse and version-control.
• Widely supported by MapLibre, Leaflet, Mapbox and many GIS/web libraries.
• Feature properties can carry flexible key/value data.
• Modern GeoJSON uses WGS84 longitude/latitude coordinates by specification convention.

KML — presentation and Google Earth workflows

• XML-based and commonly used by Google Earth and My Maps exports.
• Can carry styling, folders, overlays and time information.
• KMZ is a compressed container that commonly wraps KML and related assets.
• Conversion tools may not preserve every style or extension field.

GPX — built around GPS points, routes and tracks

• Common exchange format for GPS devices and activity/navigation apps.
• Core structures include waypoints (wpt), tracks (trk) and routes (rte).
• Elevation and timestamps are commonly stored per point.
• GPX is not designed as a general polygon format.

What conversion can lose

Geometry often converts cleanly between formats, but styling, arbitrary properties, timestamps or format-specific extensions may not. A polygon exported to GPX may become a boundary-like track because GPX has no native polygon object. Keep the original source file whenever the data matters so you retain an audit trail.

A practical decision table

What usually breaks during conversion

The geometry is often the easy part. The hard part is everything wrapped around it. KML may contain style maps, icons, folder hierarchy and overlays that have no direct GeoJSON equivalent. GPX can include extensions from fitness or navigation devices that a generic converter does not understand. GeoJSON properties can be arbitrarily rich, but many target formats only have a smaller fixed vocabulary. A successful conversion therefore means more than 'the file opened'; it means checking whether the fields you care about survived.

A safer conversion workflow

• Open the original file first and record feature counts, geometry types and basic bounds.
• Convert a copy, never the only source file.
• Open the converted output and compare feature counts and map extent with the original.
• Spot-check names, timestamps, elevation and any custom properties important to the job.
• Document known losses, especially style information and format-specific extensions.

Think about the next user, not just the current file

Choosing a format is easier when you start from the next person or system in the workflow. A field team may need a GPX track on a handheld device. A web developer may need GeoJSON because properties must be filtered in JavaScript. A client reviewing a project in Google Earth may prefer KML because folders, labels and styles are visible without specialist software. The best format is therefore often the one that preserves the information your next step actually uses.

This also explains why there is no universally superior format. GeoJSON is elegant for web data, but a long GPS track with timestamps and device extensions may be more naturally represented as GPX. KML can be verbose, but it is good at presentation. The mistake is forcing every dataset into one favorite format and discovering the lost detail later.

Example: converting a recorded hike

Suppose a hiking watch exports GPX containing a track with timestamps and elevation. You want to show the route on a website. Converting the geometry to GeoJSON is reasonable because the web map can draw the line easily and attach summary properties. But if you discard the original GPX, you may lose the point-by-point timing or device-specific metadata needed later for pace or elevation analysis.

A safer workflow is to inspect the original in the GPX Viewer, record the track and waypoint counts, then create the web-friendly version. If a developer later needs a simpler interchange file, GeoJSON Viewer provides a quick visual sanity check after conversion.

Example: a styled Google Earth project

A KML file can contain placemark icons, line colors, folder hierarchy, descriptions and ground overlays. Exporting its geometry to GeoJSON may preserve points and lines perfectly while flattening the presentation logic that made the project readable. If the objective is analysis, that trade-off might be acceptable. If the objective is to hand the project to another Google Earth user, KML is probably the better delivery format.

Validation checks that catch most conversion problems

• Feature count before and after conversion.
• Geometry types: points, lines and polygons should not unexpectedly disappear or change meaning.
• Bounding box: the output should occupy the same general part of the world as the source.
• Attributes: spot-check names, IDs, timestamps, elevation and category fields.
• Coordinate order: GeoJSON uses longitude, latitude; CSV sources are frequently the opposite.
• Character encoding: place names with accents or non-Latin scripts should survive intact.

For tabular sources, the CSV to Map tool is a useful intermediate check because a bad longitude sign or swapped column is visually obvious. For KML, open the source first with the KML Viewer before deciding what can safely be simplified.

Storage size is not the only performance question

A huge GeoJSON file can be slow in a browser because the entire structure may need to be parsed and drawn at once. GPX and KML can also become large, especially with dense tracks or embedded metadata. For production mapping, you may eventually need simplification, tiling, server-side filtering or a spatial database. File conversion is only the first layer of the architecture.

For a one-off map, keeping the original and one convenient working copy is usually enough. For a repeatable pipeline, document what you remove, how you transform coordinates and which fields are considered authoritative. That documentation is more valuable than arguing about file extensions in isolation.