Convert GPX to KML

Both destinations open in Google Earth and both show the same route, so the choice between them is about what happens next rather than about what it looks like. KML is a single XML document you can open in any text editor, diff against yesterday's version, load as a vector layer in QGIS or ArcGIS, and edit with a script. That is why this page exists separately from the KMZ one.

If what you actually need is to attach the track to an email, hand it to a colleague or upload it somewhere that asked for a Google Earth file, the compressed form is the better answer and costs you nothing but editability. The same content measured here shrinks by roughly a factor of five once it is zipped. Choose KML when the file is a working document and KMZ when it is a deliverable.

A GPX trackpoint carries a `<time>` element, and that is what makes a GPX a recording rather than a drawing: the file knows not only where the line goes but when each part of it was reached. A KML LineString has no equivalent. It is a list of coordinates and nothing more, so the timestamps are dropped in the conversion and cannot be recovered from the output.

The consequence is concrete. Google Earth's time slider, which lets you scrub through a track and watch it draw itself, will not appear for a converted file — that feature keys off a gx:Track element with parallel `<when>` values, and this conversion writes a plain LineString. Anything you want to compute about pace, moving time or stops has to be done from the GPX. Keep the original alongside the KML; they are not interchangeable, and the KML is the lossy one.

Where a GPX trackpoint carried an `<ele>` value, the coordinate written for it is a triple and the third slot holds the metres. Where it did not, the coordinate is a pair and there is no third slot to read — which is the normal state for a route planned in a browser rather than recorded on a watch. So the elevation profile of a recorded walk survives byte for byte and a tool that reads KML as data will find it; a planned route has nothing there to find, and neither case produces an error.

Google Earth will not draw it, and the reason is a single element that is absent. Altitude in KML is meaningless without an `<altitudeMode>` saying how to interpret it, and when none is declared the default is `clampToGround` — the altitude is ignored and the line is laid on the terrain. That is the right default for a track, since a GPS altitude wanders by tens of metres and a line floating raggedly above a ridge looks broken. If you want the line drawn in the air, add `<altitudeMode>absolute</altitudeMode>` to the LineString by hand.

Each LineString is written with `<tessellate>1</tessellate>`, and it is there to fix a specific visual failure. Clamped to the ground without tessellation, Google Earth places each vertex on the terrain and then draws a straight segment between consecutive vertices. Across a valley or over a ridge, that straight segment passes below the surface, and the track disappears into the hillside and reappears on the other side.

With tessellation on, the renderer subdivides each segment and follows the terrain between the vertices, so the line stays visible along its whole length. The cost is more geometry for the renderer to handle, which is imperceptible for a few thousand points and noticeable if you load a dozen long tracks at once. If a file ever feels sluggish in Earth, that flag is the first thing worth turning off.

GPX writes latitude and longitude as separate attributes on the trackpoint, named so there is no ambiguity. KML writes them as one comma-separated string in the order `longitude,latitude,altitude`, which is the opposite of nearly every other format in this family and the classic source of maps that appear in the Gulf of Guinea.

The conversion handles the swap, and there is a quick way to satisfy yourself it did. Open the KML in a text editor and look at the first coordinate: for anywhere in Britain or Ireland the first number will be small and negative and the second will be between 50 and 59. If the large number comes first, something has re-swapped it, and every point in the file is wrong in the same way.

A GPX `<wpt>` element is a point somebody deliberately marked — a summit, a water source, a parking spot, the gate that was locked. Each one becomes its own Placemark containing a `<Point>`, keeping the name it had, so they show up in Google Earth as labelled pins in the sidebar rather than being merged into the line.

That separation is worth having because waypoints and trackpoints mean different things. A trackpoint is a sample the device took on a schedule; a waypoint is a decision a person made. Keeping them as distinct KML features means you can hide the route and keep the pins, or drag a pin to correct it, without touching the recorded line at all.

Three names are carried. The `<name>` inside the GPX `<metadata>` block becomes the KML Document name, which is what shows at the top of the sidebar in Google Earth. Each track's own `<name>` becomes the name of its Placemark. Each waypoint's name becomes the name of its pin.

The rest of the GPX header does not cross over. Author, copyright, the link back to the recording service, the description, the keywords and the bounding box are all defined in GPX 1.1 and none of them is written into the KML. Nor are the per-trackpoint extensions where watches store heart rate and cadence. If any of that is the provenance you need to keep, keep the GPX file next to the KML rather than expecting one file to hold both.

The output contains no `<Style>` and no `styleUrl`. Google Earth therefore applies its default line appearance, and every converted track looks the same as every other one — which is exactly what you want when you are about to restyle it, and mildly inconvenient when you are loading eight tracks at once and want them distinguishable.

Adding styling afterwards is straightforward in either direction. In Google Earth, right-clicking the placemark and choosing its properties sets colour and width and saves them back into the file. In a text editor, a single `<Style>` block with a `<LineStyle>` colour and width, referenced by a `styleUrl` on each placemark, does the same thing and is easy to script across a folder of converted tracks.

The KML is substantially smaller than the GPX it came from, which surprises people who expect a conversion to cost bytes. Measured on a 7,200-point track — two hours recorded once a second, with elevation and time on every point — the GPX was about 950 KB and the KML about 258 KB. XML tag overhead is the reason: GPX repeats `<trkpt>`, `<ele>` and `<time>` markup around every sample, while a LineString states its coordinates once and separates them with whitespace.

Part of that saving is the timestamps being dropped, so it is not a free lunch. What you keep is a file that is still readable and editable: you can open it, find a stray point that the GPS threw into a field two kilometres away, delete that line and save. Doing the same edit to a GPX means deleting four lines instead of one, and doing it to a KMZ means unzipping first.

Parsing the GPX and writing the KML both happen in this browser tab. No request carries the file to a server, which the network panel will show during a conversion, and the page keeps working offline once loaded. There is no upload queue and no copy left behind.

For a route file that is a stronger guarantee than it sounds. A GPX from a watch usually begins and ends at the recorder's home, and the timestamps say which mornings the house was empty. Even with the times dropped on the way to KML, the shape of a regular commute or a training loop identifies a person and an address to anyone who looks at it on a map.