Convert KML to KMZ

KMZ was designed to solve a packaging problem. A KML that uses custom pin graphics, a photo overlay or a georeferenced scan refers to those files by relative path, and the moment the document is emailed on its own the references break and the map arrives blank. Bundling the document and its assets into one archive fixes that, and it is the reason the format exists.

The second reason is plainer: a KML is verbose text and text compresses. If your document has no external assets — a set of pins, a drawn route, an export from a database — then packaging is not what you are buying and size is. That is the case this conversion serves, and it serves it well, but it is worth naming which of the two you are actually after before you convert.

Measured on a KML holding a single 7,200-vertex line with elevation on every point, the document was about 258 KB and the archive about 47 KB — a factor of five and a half. Coordinate lists are close to the ideal case for a deflate: every entry shares a prefix with the one before it, the separators repeat forever, and the digits that do vary sit in the low positions.

A document made of many short placemarks compresses less well, because the ratio is dominated by the repeated element markup rather than by the numbers, and a document that is mostly prose in description balloons compresses like prose. None of those distinctions changes the decision much, but the guarantee is narrower than it looks. The writer keeps the uncompressed form when deflating would not help, so the payload never grows — the ZIP structure around it does. A local header, a central-directory entry and the end record cost 112 bytes for a file named doc.kml, and the KML inside is re-written rather than copied byte for byte, so a very small document can come out a little larger than it went in. Above a few kilobytes that is noise.

This is the part to understand before converting. The conversion does not take your KML and zip it. It parses the document into the same internal shape every GPS format on this site passes through — points with a position, an optional elevation, an optional time, grouped into named lines and pins — and writes a fresh KML out of that shape, which it then compresses.

The consequence is that the KML inside the archive is not byte-identical to yours, and in most cases is not even close. It will be shorter, its elements will be in a different order, and everything the internal shape has no room for will be absent. If you unzip the result expecting to find your own file, you will not: you will find a clean minimal document describing the same geometry.

Specifically: `<Style>` and `<StyleMap>` definitions and the `styleUrl` references to them, so line colours, widths and custom icons are gone. `<description>` balloons, including any HTML in them. `<ExtendedData>` and schema-typed custom fields, which is where anything database-derived usually lives. `<Folder>` grouping, since the internal shape has one flat list. `<LookAt>` and `<Camera>`, so the view the author chose is not restored. `<NetworkLink>`, `<GroundOverlay>` and `<ScreenOverlay>` entirely.

What survives is the geometry and the labels: every Point becomes a Placemark with a Point, every LineString and gx:Track becomes a Placemark with a LineString, and each keeps the `<name>` it had. The document name is carried. For a file whose content is where things are and what they are called, that is everything. For a styled presentation map, it is a small fraction, and the next section is the better route.

If the KML carries styling or descriptions you need, the faithful package is one you make by hand. Rename your document to `doc.kml`, add it to a ZIP archive so that it sits at the root rather than inside a folder, and rename the archive from `.zip` to `.kmz`. Every operating system can do both steps without extra software, and the result is a KMZ whose document is your document, unchanged.

The root position is the detail people get wrong. A KMZ whose KML sits one directory down opens in some readers and fails silently in others, and the failure looks like an empty map rather than an error. If you built the archive by right-clicking a folder, that is what happened — select the file itself, not the folder around it.

A `<NetworkLink>` is a KML that contains no data at all: it holds a URL and instructions for refreshing it, and everything you see when you open it was fetched from a server after the file loaded. Live traffic layers, subscription datasets and shared team maps are all built this way, and the file on disk is often only a few kilobytes.

Fed to this conversion, such a file yields no placemarks and no lines, and the result is the message that no track or waypoints were found. That is the correct outcome rather than a parsing failure, and it tells you something useful: the map you were looking at was never in the file, so there is nothing local to compress and no offline copy to make. Downloading the linked resource is the only way to get the data itself.

Google Earth, saving a KMZ, walks the document for every referenced asset and copies each one into the archive, rewriting the paths as it goes. That gathering step is the substance of what a KMZ authoring tool does, and this conversion does not attempt it.

The output holds one document and no assets, so a KML referencing local icon files produces an archive that is smaller than expected and incomplete as a package. Since the styling that referenced them was dropped during the rewrite anyway, the two limitations cancel into one consistent result rather than a half-broken file: what you get is plain geometry, drawn with the reader's default appearance, and nothing dangling.

Compression is not the only way to make a large KML manageable, and sometimes it is the wrong one. A 40 MB document that is slow in Google Earth is slow because of the number of features it draws, and zipping it to 7 MB changes the transfer time and nothing about the rendering — it decompresses to the same 40 MB before anything appears.

If the problem is performance rather than transfer, the fixes are structural: split the file by region or by layer so each one loads alone, thin dense lines that carry a vertex every metre, or move the data into a format built for volume. If the problem is genuinely that an email will not carry the attachment or an upload form has a ceiling, the archive is exactly right and this conversion is the fastest way to it.

Converting the archive back to KML afterwards returns the minimal document, not the file you started with. The rewrite happened on the way in, and nothing downstream can restore a style block, a description balloon or a custom field that was discarded before the zip was written. The two conversions compose into one lossy step rather than cancelling each other out.

That is the practical reason to keep the original rather than treating the archive as its replacement. Storage is not the constraint — the source document is the larger of the two by a factor of five and still measured in hundreds of kilobytes — and it is the only copy holding the styling, the folder structure and the database fields. Treat the KMZ the way you would treat a PDF exported from a document: the thing you hand over, not the thing you maintain.

The document is parsed, rewritten and zipped in this browser tab. No request carries it anywhere, which can be confirmed in the network panel during a conversion, and the page continues to work with the connection off.

That is worth more than usual for this particular pair, because the obvious alternative is a file-compression website. A KML of sites, customers, assets or property is business data with locations attached, and the usual route to making it smaller involves handing it to a stranger's server, waiting, and downloading it back. Doing the zip locally removes that hop rather than asking you to be comfortable with it.