Convert KMZ to CSV

KMZ files rarely originate with the person trying to open one. They arrive as an attachment from a surveyor, a utility, a council planning department, a tourism board or a contractor, produced by whichever tool that organisation standardised on, and they assume Google Earth on the other end. If you have a work order to raise or a count to verify, installing a globe viewer to read forty coordinates is a poor trade.

That is the situation this conversion is for. It opens the archive, reads the document inside and gives you the positions and names as rows — enough to paste a coordinate into a form, cross-reference against an asset register or confirm that the file really does contain the eighteen sites the email claimed. What it will not give you is the map, and if the map is the deliverable then Google Earth is genuinely the right tool.

There is no KMZ data model. The format is a ZIP archive whose main member is a KML document, and everything a KMZ can express is expressed by that KML. The archive exists so that a map can travel as one file together with the images it references — custom pin icons, a photo overlay, a scanned plan georeferenced onto the terrain — rather than as a folder that breaks when one file is left behind.

The reader looks for `doc.kml`, which is the name Google Earth writes, and falls back to the first member ending in `.kml` if that name is absent. The fallback is not defensive padding: the specification requires only that the archive's main document be a KML, and files exported by other tools carry names like `Sites_Phase2.kml`. If no member ends in `.kml` at all, the conversion stops with a message saying so rather than producing an empty table.

A KMZ that is 4 MB is almost never 4 MB of coordinates. The bulk is usually a `files/` or `images/` folder holding icon PNGs, a JPEG overlay, occasionally a scanned site plan several thousand pixels across. None of that is represented in the CSV, and it is not being silently dropped by an oversight — a table has nowhere to put a raster image, and a column of filenames referring to files you no longer possess would be actively misleading.

The practical consequence is that a KMZ whose real content is a picture converts to a nearly empty CSV. A georeferenced plan with two corner markers gives you two rows and none of the plan. If that is what you find, the archive is a document rather than a dataset, and unzipping it by hand to look at the image is the answer rather than a different converter.

Every row carries a type, a name, a latitude, a longitude, an elevation and a time. Type distinguishes a single dropped point from a vertex of a drawn line, and it is the first thing to filter on: a KMZ of asset locations should be entirely `waypoint` rows, and a large block of `track` rows means the file contains routes or boundaries as well.

Name is the label the placemark carried, repeated on every vertex of a line so that filtering a single feature out of a large file needs no joining. Latitude and longitude are decimal degrees, which is what a mapping search box, a fleet system and a geocoding API all accept directly. Elevation and time are frequently empty, because a drawn map records neither, and empty is the correct output for a value the source never held.

Changing the extension to `.zip` and double-clicking is a legitimate way to get at the contents, and worth knowing about because it costs nothing and confirms what the file actually is. Every desktop operating system will open it, and you will see the KML alongside whatever images travelled with it.

What you have then is XML: coordinates written as `longitude,latitude,altitude` triples run together inside a single element, wrapped in placemark and folder structure, with the longitude first. That is readable by a person hunting one number and unusable as a dataset. The conversion does the second half — the walk through the folder tree, the coordinate split, the reversal into latitude-first — which is the part that is tedious by hand and easy to get wrong.

Compression makes the file on disk a bad guide to how much is inside. KML is repetitive text, which deflates unusually well: a KML of roughly 258 KB measured here compressed to about 47 KB inside the archive, a factor of five and a half. A 3 MB KMZ can therefore hold something like 15 MB of KML and several hundred thousand coordinates.

The 100 MB free ceiling applies to the KMZ as it stands, so in practice the limit you meet first is your browser tab's memory rather than the number. If a large archive stalls, the useful diagnosis is to rename it to `.zip` and look at the uncompressed size of the KML member — that figure, not the archive size, is what has to be parsed and held.

Two distinct failures produce something that looks like nothing. If the archive holds no KML member, the conversion says so explicitly, and the cause is nearly always a file that was renamed rather than exported. If the KML is present but yields no geometry, the message is that no track or waypoints were found, which is a different problem with a different fix.

The usual cause of the second is that the file consists of polygons. Areas — a parcel boundary, a flood zone, a coverage footprint — store their outline inside a `<Polygon>` element that this reader does not descend into, so a KMZ of nothing but shaded regions produces no rows. Network links, which fetch their content from a URL rather than storing it, come back empty for the more fundamental reason that the archive genuinely contains no data.

The name of each placemark comes across. Almost nothing else that a professional export carries does, and on this kind of file that is the omission most likely to matter: the asset number, the pipe diameter, the inspection date, the parcel reference and the surveyor's note usually live in the `<description>` balloon or in an `<ExtendedData>` block, and neither is read. A KMZ that looked information-dense in Google Earth can convert to a table of names and numbers with all the substance missing.

Two routes recover it. Rename the archive to `.zip`, extract the KML and read it — the extended fields are verbose but perfectly legible, and a `<SimpleData name="asset_id">` element says what it is. Or ask the sender for the table the KMZ was generated from, which almost always exists, because a file with a custom schema in it came out of a database rather than out of somebody drawing on a globe.

Latitude and longitude are written as plain decimal degrees to six places, about 11 centimetres — far finer than the source data justifies and coarse enough to keep the file readable. That format goes straight into the search box of any mapping site, into a fleet or dispatch system, and into a geocoding API without conversion, which is usually the immediate reason somebody wanted the table at all.

The one thing to watch is the order the destination expects. Written as `48.137154, 11.576124` a mapping search reads latitude first and lands where you meant. A system built on GeoJSON or on a GIS library often wants longitude first, and swapping the pair moves a point in Munich to the sea off Somalia — far enough that the error is obvious the first time and easy to miss when it happens to one row in four hundred.

The archive is unzipped, parsed and rewritten inside this browser tab. Nothing is transmitted, which the network panel will confirm during a conversion, and the page keeps working with the connection off. There is no account to create and no file sitting in a queue afterwards.

For this pair the argument is contractual as much as personal. A KMZ from a client, a utility or a public body frequently arrives under terms about where it may be stored, and pasting it into a free web converter is exactly the kind of transfer those terms are written to prevent. Doing the conversion locally means there is no third party to name, and no processing agreement to go and find.