What is a KMZ file?

KMZ is a container: a wrapper that holds streams encoded by something else. It is used for mapping.

The extension is .kmz, and the full name is Zipped KML. Both matter less than what the file can hold, which is what the rest of this page is about.

It comes from Keyhole. The specification is OGC KML 2.3.

Age is worth knowing here for one practical reason: the older a format is, the more programs have had time to learn it.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

KMZ stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

KMZ stores a directory: names, folders and the structure between them. That is what lets it stand in for a folder in an email attachment.

Google Earth and QGIS read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

KMZ is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

A KMZ is an ordinary ZIP archive containing one KML document and everything that document refers to: custom placemark icons, photographs, ground overlay images, occasionally a model. Rename it to .zip and any archive tool opens it, which is not a trick — it is how the format is specified.

The KML inside is conventionally called doc.kml and sits at the root of the archive. Everything else lives in folders beside it, referenced by relative path, which is what makes the whole package portable in a way a bare KML never is.

Because a KML referencing images on your own computer shows nothing on anybody else’s. The moment a map uses a custom icon, a photograph in a balloon or an overlay, the file stops being self-contained, and sharing it produces a map with missing pieces and no explanation.

Packaging solves it completely. Everything travels together, the relative paths still resolve, and the recipient opens one file. Google Earth defaults to KMZ for exactly this reason, and it is the right default even for a map with no images yet — because one will be added eventually.

KML is verbose XML, and coordinate lists in particular are enormously redundant text. Zipping typically takes a large dataset to a fifth of its size, sometimes a tenth, and that is before any images are considered.

For a file being emailed or put behind a link, that matters. For a file being edited, it does not — unzip, work on the KML in a text editor or in Google Earth, and repackage. Nothing is lost in either direction, because compression is all the container is doing.

Three situations. A tool that reads KML but not KMZ, which is more common than it should be among GIS utilities and web viewers. A bulk edit — a find-and-replace across two thousand placemark descriptions is a text operation and wants the raw file. And diagnosis, when a map shows nothing and you need to know whether the images are actually in the package or merely referenced.

That last one is the most useful. Open the archive, look at the folders, and compare what is there against what the KML asks for. A missing icon or overlay shows up immediately, and it explains a class of problem that is otherwise invisible from inside Google Earth.

Packaging protects local files. It does nothing for remote ones. A KML that pulls an overlay from a URL, or uses a network link to fetch live data, still depends on that server being there — and a KMZ built around one is a few kilobytes that show nothing once the source goes away.

The other gap is fonts and formatting inside description balloons, which are HTML. A balloon styled with a font the recipient does not have, or pointing at an image on the web, degrades the same way any web page does. If a map must work offline and permanently, everything it needs has to be a file in the archive.

Zip the KML and its asset folders together, with the KML at the root of the archive, and rename the result to .kmz. That is the entire process — there is no special tool and no manifest to write.

Two details worth getting right. Zip the contents, not the enclosing folder, or every path inside the KML gains a directory level and nothing resolves. And keep the relative paths as they are: the references inside the KML are what the archive structure has to match, so the folder layout is not cosmetic.

Google Earth, on the desktop, on mobile and in the browser version. Google My Maps imports one directly, which is the usual way a shared map ends up on the web. QGIS reads it for analytical work, and most serious GIS software will, though several want it converted to GeoJSON or Shapefile first.

What does not open one is a browser on its own, a mail client preview, or any general file viewer. Sending a KMZ to somebody who does not already use Google Earth means sending them a file and an instruction, which is worth knowing before it becomes a support conversation — a link to a My Maps view is often the better thing to send.