GPX to KML Converter: GPS Tracks into Google Earth

Apps
All tools
Report

Heading to the field? Install this site from your browser menu and this tool works with no signal. See how

Converter

Nothing is uploaded. The file is converted on your own device, so it works with no signal.

Drop a file here or

Nothing leaves your device.

No file to hand?

Waiting for a file.

Features in this file

NameTypeFolderVerticesLengthArea

A side by side comparison of the same point written in two formats. On the left, GPX writes it as a wpt element with lat equals 37.0 and lon equals minus 109.05 as named attributes, latitude first. On the right, KML writes it as a coordinates element containing minus 109.05 comma 37.0 as plain text, longitude first and unnamed. A red panel explains that swapping them claims a latitude of 109 degrees, which does not exist because latitude stops at 90, and that software variously clamps it, rejects the file or drops the feature.
Because GPX names its two values, this direction cannot get the order wrong. The risk is entirely in hand edited KML, where position is the only clue.

How to use this tool

Drop a .gpx file above. Waypoints, routes and tracks are all read, drawn on the map and listed, then press Convert to KML and download. What you get is a .kml file that opens in Google Earth by double clicking it.

If you would rather have the compressed single file, which for a recorded track is dramatically smaller, use the GPX to KMZ Converter instead. The contents are identical.

What Google Earth gives you that a GPS screen cannot

The reason to make this conversion is not storage, it is context. A GPS unit draws your track on a small screen against a basemap it shipped with. Google Earth drapes the same track over terrain, aerial imagery and buildings, and lets you tilt the view.

For a walked route that means you can see which side of the ridge you were on. For a survey traverse it means you can see whether a line crosses a river or a fence. That is the whole argument for this conversion, and it is why the destination is almost always someone who wants to look rather than to navigate.

The coordinate order reverses, and why that is safe here

GPX and KML store position in genuinely different ways, and this is worth understanding because it is where hand edited files go wrong.

GPX writes position as attributes on the element: lat first, then lon, each one named. KML writes position as text inside a coordinates element, longitude first, with nothing but the order to tell you which is which.

So the same point is lat="37.0" lon="-109.05" in GPX and -109.05,37.0 in KML. Same numbers, opposite order, and only one of the two formats names them.

Because GPX names its values, reading one is unambiguous, and this conversion cannot get the order wrong. The risk lives in the other direction, in KML that somebody typed by hand. Swap the pair there and you are claiming a latitude of 109 degrees, which does not exist, because latitude stops at 90. Some software clamps that to the pole, some rejects the file, and some quietly drops the feature. All three look like a converter losing your data.

A worked check you can repeat on paper

Load the sample and convert it, then open the resulting KML in a text editor. The trailhead waypoint went in as lat="37.0" lon="-109.05" and comes out as a coordinates element reading -109.05,37.0. Two numbers, order swapped, values untouched.

Now check the track. The sample has one track in two segments. In KML that becomes a MultiGeometry holding two LineString elements, not one line with a jump in it. Count the coordinate pairs: three in the first LineString and two in the second, matching the trkseg elements they came from.

That is the detail worth verifying in any converter you use. If the output has a single LineString with five points, the two segments were joined, and any distance calculated from it includes 14.108 km of ground the recorder never covered.

How this was checked

The conversion is verified in both directions against an independently written implementation running outside the browser. A GPX goes in, becomes KML, is parsed back by the second implementation, and the feature count, the total length and the bounding box are compared.

The full loop is also tested: GPX to KMZ and back to GPX returns the same four features, the same total length of 83650.94 m, and waypoint positions with zero drift, not merely small drift.

One bug was found this way rather than by inspection. A two segment track converted to KML becomes a MultiGeometry, and an early version of the writer had no branch for reading that back, so the whole feature disappeared with no error. Both implementations now reassemble it as one track with its segments intact, and a permanent test holds it there.

Mistakes that catch people out

Expecting the track to be navigable in Google Earth. It is not a navigation tool. It will draw your track beautifully and it will not tell you to turn left.

Sending a raw KML of a long recorded track by email. A five thousand point track is around 113 kB as KML, which is fine, but the GPX it came from was 255 kB and people often attach both. Send the KMZ instead.

Losing the distinction between a route and a track. Both become lines in KML, and once there, nothing marks which was the plan and which was the recording. Name them clearly before converting.

Assuming timestamps survive usefully. The time on each track point is carried into the KML, but Google Earth only animates it if the elements are laid out for its time slider. If you need the animation, that is a different export.

Forgetting that elevation in a GPX is measured from the ellipsoid. Google Earth will happily draw a track floating above or sunk below the terrain because of it. Clamping the track to the ground in Google Earth usually looks more like reality than the recorded heights do.

Related Calculators and Reference

This conversion usually sits between a device and somebody who wants to look at the result.