Convert KML to GPX

Almost every KML that ends up needing this conversion was made by clicking. Somebody traced a route in Google Earth, dropped pins along a My Maps layer, or exported a plan from a tool whose only export is KML. That file describes an intention: this is where the line should go. A GPX off a watch describes a history: this is where the receiver was, at these instants, at this altitude.

The conversion moves the geometry from the first into the shape of the second, and everything that makes a recording a recording is simply not in the source to move. That is not a defect of the converter, and it is worth understanding before you look at the result and think something went wrong: the flat elevation profile, the missing duration and the angular corners are all properties of the drawing, faithfully carried across.

Each LineString becomes a `<trk>` containing a single `<trkseg>`, with one `<trkpt>` per vertex, in a GPX 1.1 document. The placemark's name becomes the track name, so a device that shows a list of tracks will show whatever you called the line in Google Earth rather than the filename.

It is deliberately a track and not a `<rte>`. GPX distinguishes the two: a route is a sparse list of points to navigate between, a track is a dense line to follow. Older handheld units treat them differently, and some will offer turn prompts for a route and none for a track. If your device specifically wants a route, converting the track afterwards is a job for the device's own software — Garmin BaseCamp does it — rather than something a format conversion should decide on your behalf.

A LineString stores coordinates and nothing else, so the GPX comes out with no `<time>` element on any trackpoint. The file is valid — time is optional in GPX 1.1 and a route has no business claiming one — and every navigation app will load and follow it.

Where it bites is uploading. A platform that treats a GPX as a completed activity has to compute a duration and a pace, and it cannot do that without two timestamps to subtract. Upload a drawn route as a route or a course, which is the feature built for exactly this file, rather than as an activity. If a service rejects the file with a complaint about missing time data, that is what it is telling you, and adding fabricated timestamps would produce an activity that claims a speed nobody rode.

A KML coordinate has an optional third value in metres. Google Earth, drawing a line clamped to the terrain, writes that third value as `0` on every vertex, because the altitude is meaningless when the renderer is going to lay the line on the ground anyway. The conversion takes the number at face value, so every trackpoint gets `<ele>0</ele>` and your device draws a profile flat at sea level with no ascent.

A My Maps export often behaves differently, writing only two values per coordinate, in which case no `<ele>` element is written at all — which is the more honest outcome and looks identical on most devices. Either way the elevation has to come from somewhere else. Most route planners will regenerate it from a terrain model on import, and that number is better than the zero anyway, since it comes from a survey rather than from a receiver bouncing around on a hillside.

The conversion writes exactly as many trackpoints as the KML had vertices and never interpolates. A day-long route traced by clicking is commonly forty to two hundred vertices; the same route recorded by a watch at one sample a second is thirty thousand. On a map at low zoom the two look identical. Zoomed in, the drawn one cuts corners, crosses a river where no bridge is, and follows a straight line through a switchback.

That matters most for anything that measures. Distance computed along a coarse polyline is systematically short, because every curve has been replaced by its chord, and a mountain descent with fifteen hairpins can lose a meaningful fraction of its length. If the number matters, plan the route in a tool that snaps to the road or path network — the result is denser and follows real geometry — and use this conversion for lines whose exact shape you drew on purpose.

A Placemark holding a `<Point>` becomes a GPX `<wpt>` at the same position, keeping the name it had. Waypoints are written before the tracks in the file, which is the conventional order and the one handheld units expect. On most devices they appear as points of interest you can select and navigate to independently of the route.

This is often the more useful half of the conversion. A layer of thirty pins — water stops, gates, campsites, meeting points — becomes thirty labelled entries on a watch, which is something no amount of staring at a route line gives you. Names are carried verbatim, so it is worth making them short before converting: a screen showing eleven characters truncates "Water refill point by the bridge" to something unhelpful.

Two constructs in KML come back with nothing. A `<Polygon>` — a boundary, a permit zone, a shaded region — keeps its outline inside nested boundary elements that this reader does not open, so an area contributes no track. A `<MultiGeometry>`, which wraps several lines or points inside one Placemark, is skipped for the same structural reason.

If the whole file is built that way, the conversion stops and says that no track or waypoints were found, which is accurate rather than a failure to try. The workaround, when the outline is what you want to follow, is to reopen the KML in Google Earth and redraw the boundary as a path — a Polygon and a LineString look the same on screen and are different objects in the file. It takes a minute and produces something every device can read.

If the KML came from a GPS export rather than from drawing, it may hold a `gx:Track` instead of a LineString: Google's extension, storing a list of `<when>` timestamps alongside a matching list of `<coord>` positions. It is read as a distinct case, and the timestamps are carried straight through into the `<time>` element of each GPX trackpoint.

That single difference changes what the output is good for. A GPX converted from a gx:Track is a recording, with a duration and a pace, and it uploads as an activity like any other. The quick way to tell which kind of KML you have is to search the file for `when` — if the string is there, expect timestamps in the GPX, and if it is not, expect none. The coordinates inside a gx:Track are separated by spaces rather than commas, so a file can legitimately use both conventions at once.

Placemarks nested in Document and Folder elements are found by walking the tree, which is necessary because a My Maps export puts every layer in its own folder and a KML from a planning tool can be three levels deep. The folder names themselves are not carried: GPX has no equivalent grouping, and inventing one would mean guessing which level mattered.

What does come across is the Document name, which becomes the GPX `<metadata><name>`, and each placemark's name, which becomes the name of its track or waypoint. The file is written with GPX 1.1 and a creator attribute naming this converter, so a device that reports where a file came from will say so. Nothing else from the KML header — descriptions, style definitions, the LookAt camera position — has a place in a GPX and none of it is written.

The KML is parsed and the GPX is written in your browser. No request carries the file anywhere, which can be checked in the network panel while the conversion runs, and the page works with the connection off once it has loaded.

A planned route says less about you than a recorded one, but not much less. A drawn line still names where you intend to be and when you intend to be there, and a My Maps layer of client sites or property viewings is commercially sensitive before it is personal. Converting locally means the file never becomes somebody else's log entry, which is the only guarantee that does not depend on reading a retention policy.