Convert KMZ to GPX

KMZ is the format organisations publish in. National park services, trail associations, event organisers, land agents and surveyors all export from tools that produce Google Earth files, and the archive form is preferred because it travels as one attachment and looks like a map when it is opened. None of that helps if the route has to end up on a wrist.

Watches, bike computers and navigation apps are built around GPX. The conversion takes what the publisher drew and rewrites it in the form the device expects: lines become tracks, pins become waypoints, names come with them. What the publisher wrapped around the geometry — the styling, the imagery, the folder structure — is not part of what a device follows and does not survive.

A KMZ is a ZIP whose principal member is a KML document. The reader unzips it in the browser and looks first for a member called `doc.kml`, the name Google Earth writes when it saves. When the archive was produced by something else, the document may be called anything at all, so the fallback is the first member whose name ends in `.kml`.

That fallback is not defensive decoration: exports from GIS software routinely name the document after the layer, and an archive from a survey team might hold `Route_final_v3.kml` and nothing called `doc` at all. If there is no KML member of any name, the conversion stops with a message saying so, which almost always means the file is a renamed ZIP of something unrelated.

Open a published KMZ as a ZIP and the KML is often the smallest thing in it. Alongside sit the pin graphics the map uses, a legend image, sometimes a georeferenced scan of a printed trail map draped over the terrain, occasionally photographs pinned to viewpoints. That is exactly what the archive format exists to carry, and it is why the publisher chose it.

GPX has no element for any of it. A GPX waypoint is a position, a name and optionally a comment; there is no image, no style, no overlay. So the conversion writes the geometry and leaves the rest in the archive, which is the only honest option. If the trail map picture is the part you actually wanted, extract it from the archive by renaming the file to `.zip` and keep it on your phone alongside the GPX.

Every LineString anywhere in the document becomes a `<trk>` with one `<trkseg>`, keeping the placemark name as the track name. Every Placemark holding a `<Point>` becomes a `<wpt>` with its name. Waypoints are written first, which is the conventional order and the one handheld units expect when they build their point-of-interest list.

Names are the part worth checking before you sync. They come across verbatim, and published KMZ files frequently label features for a legend rather than for a small screen — `Section 4 (blue waymarks, seasonal closure Nov–Mar)` is informative on a monitor and truncated to nothing useful on a watch. Renaming tracks and waypoints in the GPX afterwards is a five-minute edit in a text editor and makes the file usable in the field.

A large share of KMZ files published by agencies describe regions: a hunting unit, a permit zone, a fire closure, a parcel boundary, a coverage footprint. Those are `<Polygon>` features, and their outlines live inside nested boundary elements that this parser does not descend into, so they produce no track. A KMZ made entirely of them converts to nothing and says so.

That message is accurate and it is also useful information about the file: you have been given a map of where something applies, not a route through it. When the boundary itself is what you want to follow — walking a property line, checking a fence — open the KMZ in Google Earth and retrace the outline with the path tool, then convert the result. A `<MultiGeometry>` placemark, which bundles several lines under one entry, is skipped for the same structural reason and has the same fix.

A KML coordinate can carry altitude as its third value, and the conversion writes it into `<ele>` when it is there. The catch is what publishers actually write. A line drawn in Google Earth and clamped to the terrain carries an altitude of zero on every vertex, because the renderer is going to lay it on the ground regardless, so the GPX arrives with a profile flat at sea level.

A device shown that file reports no ascent, which is the correct reading of the data it was given. Route planners and training apps generally re-derive elevation from their own terrain model on import, and the result is better than what a receiver measures anyway. If you need a profile before you leave, load the GPX into a planner rather than trusting the numbers in the file — and if the third value is missing entirely, no `<ele>` is written at all, which is the cleaner of the two outcomes.

Most published routes carry no time at all, because a LineString stores coordinates and nothing else. The GPX therefore has no `<time>` element on any trackpoint, which is valid — time is optional in GPX 1.1 — and which means the file is a course to follow rather than an activity to upload.

The exception is an archive built from a GPS export, where the document may hold a `gx:Track` with parallel lists of timestamps and positions. Those timestamps are read and carried into the GPX. The quick test is to unzip the archive and search the KML for `when`: if the string appears, expect times in the output, and if it does not, expect a course. Trying to upload a course as a completed activity is the mismatch that produces a rejection about missing time data.

Publishers often ship a network rather than a route: eight waymarked trails, a set of alternates, a main course plus its shortcuts. Every line in the document becomes its own track, so the GPX comes out holding all of them, each named as the placemark was named.

Devices vary in how gracefully they handle that. Some list every track and let you pick; some concatenate them into one implausible route that jumps between trailheads; some accept only the first. If your unit does the wrong thing, the fix is to split the GPX into one file per track before syncing, which most desktop route tools do in a couple of clicks and which also lets you drop the seven trails you are not walking.

The size of a KMZ says little about how much geometry is inside it. Coordinate text compresses extremely well — a KML measured here at about 258 KB deflated to roughly 47 KB — so a small archive can hold a document five or more times its size and hundreds of thousands of vertices.

The free limit here is 100 MB for the archive as it stands, and in practice the browser tab's memory is what you meet first on a genuinely large publication. If a big file stalls, the diagnostic worth doing is to rename it to `.zip` and look at the uncompressed size of the KML member, because that number, not the archive size, is what has to be parsed and held in memory.

The archive is unzipped, parsed and rewritten inside this browser tab. No request carries it anywhere, which the network panel shows during a conversion, and the page keeps working offline once loaded.

For a received file the argument is partly about you and partly about them. A survey or client KMZ often arrives under terms that restrict where it may be stored, and pasting it into a web converter is exactly the transfer those terms exist to prevent. A trail file is less sensitive, but the GPX you make from it is about to record where you go, and starting that chain without a stranger in it costs nothing.