Convert KMZ to KML

The first is manual. Rename the file from `.kmz` to `.zip`, open it, and take out the document — you now hold exactly what the author saved, with every style, description and folder intact, plus whatever images travelled with it. Nothing is lost because nothing has been interpreted. It costs about fifteen seconds and no software.

The second is this conversion, which reads the document and writes a new one containing the geometry and the names. That is a smaller and simpler file than the original, and sometimes that is precisely what you need: an importer that rejects a complex KML, a script that expects one shape of document, a file you are about to edit by hand and would rather not wade through. Knowing which of the two you want is most of the decision, and the manual route is the right answer more often than a converter page would normally admit.

The output is a KML 2.2 document with one `<Document>` element, a name if the source had one, and a flat list of Placemarks. Every point in the archive becomes a Placemark holding a `<Point>`; every line becomes a Placemark holding a `<LineString>` with a `<tessellate>1</tessellate>` flag so it follows the terrain rather than cutting through it. Names are carried on all of them.

That is the whole file. There is no `<Style>` block, no `styleUrl`, no `<description>`, no `<ExtendedData>` and no folder nesting, which makes it unusually easy to read and to edit: one placemark is four or five lines, and finding the coordinate you want to change means scrolling to a name rather than tracing a reference. For hand-editing, that simplicity is the feature.

Archives produced by organisations are usually styled, because they were made to be looked at. Expect `<Style>` and `<StyleMap>` definitions setting line colours and custom icons, `<description>` balloons containing HTML and sometimes whole tables, `<ExtendedData>` carrying the database fields each feature came from, and a folder tree that groups features by layer or by phase. None of that appears in the output.

Two more things go and they are worth calling out separately. A `<GroundOverlay>` — a scanned plan or an aerial image draped over the terrain — is not read at all, so an archive whose real content is a picture converts to a nearly empty document. And a `<NetworkLink>` holds a URL rather than data, so a KMZ built around one produces no placemarks and reports that no track or waypoints were found, which is accurate: the map was never in the file.

Inside, the principal member is conventionally `doc.kml`, sitting at the root of the archive rather than in a folder. That is what Google Earth writes and what readers look for first. When an archive comes from other software the document may be named after the layer instead, so the fallback is the first member whose name ends in `.kml`, and an archive with no KML member at all stops the conversion with a message saying exactly that.

This matters if you are going to repackage anything by hand. A KMZ whose document sits one directory down opens in some readers and silently shows an empty map in others, and the usual cause is zipping a folder rather than the file inside it. If you extract, edit and rezip, select the document itself and confirm afterwards that the archive lists it at the top level.

If the archive holds a `gx:Track` — Google's geometry for GPS traces, storing parallel lists of `<when>` timestamps and `<coord>` positions — the positions are read and the times are read with them. But the writer produces a `<LineString>`, which stores coordinates and nothing else, so the timestamps have nowhere to go and are dropped on the way out.

The output is therefore a shape where the input was a recording, and Google Earth's time slider will not appear for it. If the times are what you care about, this is the wrong conversion and the right one is KMZ to GPX, where every trackpoint has a `<time>` element and the recording stays a recording. It is an unusual case — most KMZ files in circulation were drawn rather than recorded — but it is the one where the loss is silent and total.

Document and Folder elements are walked recursively, so a placemark nested three levels down is found — which is necessary, because exports from mapping software routinely bury their features. What the walk does not do is preserve where they were. Everything comes out in one flat list.

For a KMZ organised by layer, that is a real loss of structure: `Phase 1 / Confirmed / Site 14` and `Phase 3 / Proposed / Site 14` become two placemarks called `Site 14` sitting next to each other. If the grouping is information you need, it has to be folded into the placemark names before converting, or the archive extracted by hand so the folders survive. A flat list is easier to script against and harder to read, which is the trade in both directions.

A KMZ is smaller than the KML it holds, so unpacking one always costs bytes. Measured here, a document of about 258 KB compressed to roughly 47 KB inside the archive, a factor of five and a half — coordinate text is close to the best case for a deflate, since every entry shares a prefix with the one before it.

Expanding it back is most of what this conversion does, and it is worth expecting the size change rather than being surprised by it. The practical limit is the 100 MB ceiling applied to the archive as it arrives, but the number you will meet first on a large publication is your browser tab's memory, which has to hold the parsed document rather than the compressed one.

The normalised document is straightforward to edit by hand. Coordinates are written as `longitude,latitude,altitude` triples, one per line inside the `<coordinates>` element, with longitude first — the reverse of GPX and of most other things, and the single detail most likely to be got wrong when typing a replacement by hand. Six decimal places is what the writer produces, about 11 centimetres, and there is no benefit in adding more.

Adding styling back is a small job if you want it: one `<Style>` block with a `<LineStyle>` colour and width near the top of the document, and a `styleUrl` on each placemark that should use it. Google Earth will also do it interactively — open the KML, change the appearance in the properties dialog, and save the place, which writes the style into the file for you.

Software that claims to read KML varies enormously in how much of it it actually implements, and the refusals cluster around a short list: a `<Schema>` with typed `<ExtendedData>` fields, a `gx:` namespaced geometry the reader does not recognise, a `<NetworkLink>` it will not follow, a `<StyleMap>` pointing at an icon that is not in the archive. Any one of them can produce an error message that names none of them.

The normalised output contains none of it — one namespace, two geometry types, names and coordinates, and no reference to anything outside the file. That is the substance of what this conversion offers over unzipping the archive by hand, and it is the reason to try it when an import has failed for reasons nobody can pin down. If the rewritten document then loads, the problem was in the parts that got dropped, which is a diagnosis in itself and takes a minute to reach.

The archive is unzipped, parsed and rewritten inside this browser tab. Nothing is transmitted, which the network panel shows during a conversion, and the page keeps working with the connection off once loaded.

That is the practical answer to a common awkwardness. A KMZ from a client, a contractor or a public body frequently arrives with terms about where it may be stored, and the quickest way to look inside one is usually a web tool that would breach them without anybody noticing. Doing it in the browser means there is no third party in the chain and no processing agreement to go and find before you can read your own email attachment.