Convert GPX to KMZ

The reason to reach for KMZ rather than KML is that the file is leaving your machine. One attachment, a fraction of the size, and an extension that most recipients associate with a map rather than with a GPS device — a colleague who would look blankly at a `.gpx` will double-click a `.kmz` and get a globe with a line on it. If you are going to keep editing the file yourself, plain KML is the better choice and the archive is only in the way.

That is the whole basis on which these two conversions differ, and it is worth being deliberate about. KMZ is a deliverable: compact, self-contained, awkward to modify. KML is a working file: verbose, editable in any text editor, easy to diff and to script against. Neither is a better format than the other, and choosing by which one is "newer" or "more compressed" misses what actually decides it.

Measured on a synthetic track of 7,200 points — two hours sampled once a second, with an elevation and a timestamp on every point — the same route came to about 950 KB as GPX, 258 KB as KML and 47 KB as KMZ. Per point that is roughly 132 bytes, 36 bytes and under 7 bytes, and the gap between the first two numbers is not compression at all.

Two separate effects are stacked here and it is worth separating them. GPX to KML saves about three quarters of the bytes by dropping the per-point timestamps and the repeated element markup. Zipping the result saves another five and a half times on top, because a list of coordinates that all begin `11.57` and `48.13` is about as compressible as text gets. Only the second of those is reversible.

Rename the output to `.zip` and open it and you will find a single member named `doc.kml`. That is the name Google Earth writes and the name every reader looks for first, so a KMZ built this way opens without the fallback logic that a differently named document would require.

There is nothing else in there. No `files/` directory, no icons, no manifest, no second document. That makes the archive slightly unusual as KMZ files go — most in circulation carry a folder of images alongside the KML — and it makes this one trivially inspectable. If you ever need to check what a recipient will actually see, the whole content is one file you can extract and read.

KMZ exists so that a KML and the images it references can travel as one object. A map with custom pin graphics, a photo overlay, a scanned plan draped over the terrain: all of those are separate files that a KML points at by relative path, and all of them break the moment the KML is emailed on its own. The archive solves that.

None of it applies to a converted GPX, because a GPX has no images. The archive here is doing the lesser job of compressing one document, and saying so is more useful than implying you are getting a richer file than you are. If you want a KMZ that genuinely bundles photographs against positions, build it in Google Earth, where the photos are attached to placemarks and saved into the archive together.

Each track is written as a LineString, which is a list of coordinates and nothing more. The `<time>` element on every GPX trackpoint has nowhere to go and is dropped, so what arrives at the other end is the shape of where you went and no record of when. Google Earth's time slider does not appear for the file, and no software can reconstruct a pace from it.

For most reasons anyone shares a track that is fine — the question being answered is usually "which way did you go" rather than "how fast". Where it is not fine, the fix is to send the GPX alongside, or instead. A GPX is eight hundred kilobytes rather than fifty, which is a real difference on a mailing list and an irrelevant one in a single email, and it is the only one of the two files that still knows what time it was.

The archive writer tries deflating each member and keeps whichever of the two results is smaller, storing the file uncompressed when compression would not help. For a KML of coordinates it always helps and by a lot, so in practice this branch is never taken here — but it is the rule that guarantees the archive can never come out larger than its contents, which a fixed policy of always compressing cannot promise.

That is also why a very short track produces a file whose size looks dominated by overhead. A ZIP spends a local header, a central directory entry and an end-of-archive record on every member regardless of content, several dozen bytes each, so a five-point route ends up a few hundred bytes of structure wrapped around a few hundred bytes of coordinates. It is still a valid KMZ and Google Earth opens it exactly the same way.

Saved GPX waypoints become individual Placemarks holding a `<Point>`, each keeping its name, so the recipient sees them as a list of labelled entries in the Google Earth sidebar with pins on the globe. They can be toggled independently of the route line, which is what makes a KMZ of a walk more useful than a screenshot of one.

The names are carried verbatim from the GPX, which is worth a glance before sending. Devices generate names like `WPT042` when a point is marked without being labelled, and a recipient opening a file of forty such entries has been given a puzzle rather than a map. Renaming the waypoints in the GPX before converting takes less time than explaining them afterwards.

A KMZ cannot be edited in place. To change anything — remove a stray point, rename a track, add a colour — you rename the file to `.zip`, extract `doc.kml`, edit the XML, and zip it back up with the document at the root of the archive rather than inside a folder. That last detail is the one people get wrong: a KMZ whose KML sits one directory down still opens in some readers and not in others.

If you expect to iterate, keep the KML as your working copy and produce a KMZ each time you send one. That is the same discipline as keeping a document and exporting a PDF from it, and for the same reason: the compressed thing is the copy that goes out, not the copy you maintain.

A KMZ is for looking at. Watches, bike computers and navigation apps read GPX and almost none of them will load a Google Earth archive, so a reply asking how to get the route onto a head unit means the wrong file was sent. The conversion is a presentation step rather than a handover of the route itself, and it is worth being clear about that before the exchange takes three emails.

The cheap answer is to attach both. A densely recorded GPX is under a megabyte, the archive is a few tens of kilobytes, and together they cover the two things anyone is likely to want: see it now, follow it later. If only one can go, the deciding question is which of those the recipient is doing — and it is quicker to ask than to guess, because the two answers point at different files.

Reading the GPX, writing the KML and zipping the archive all happen in this browser tab. No request carries the file anywhere, which the network panel confirms during a conversion, and the page works with the connection switched off once loaded.

It is worth noticing the shape of the alternative. The usual way to compress a file before emailing it is to upload it to a service that compresses it and sends it back, which means the track — your addresses, your times, your habits — has been through somebody else's machine purely so that an attachment would be smaller. Doing the zip locally removes the trade entirely rather than mitigating it.