KMZ

KMZ is a compressed, zipped archive that bundles a KML file together with any images, icons, and 3D models it references, into one shareable package.

Extension

.kmz

Full name

Zipped Keyhole Markup Language

Introduced

Introduced alongside KML by Keyhole, Inc. in the early 2000s as the compressed distribution format for Google Earth content

Vendor

Keyhole, Inc. (acquired by Google in 2004); the KML format it wraps is OGC-standardized

What is inside the container

A KMZ file is a ZIP archive that, by convention, contains one KML file named doc.kml at its root alongside an images or files folder holding the icons, ground-overlay textures, and 3D models the KML references. Unzipping a KMZ produces a valid standalone KML plus its assets, so KMZ is best understood as KML's packaging solution to the exact companion-file problem that plain KML (and, differently, Shapefile) is prone to.

How to open it

Desktop/Earth browser Google Earth Pro opens KMZ directly, unpacking it in memory

Desktop GIS QGIS reads KMZ through its OGR-based vector data provider

Archive tools Any standard zip/unzip utility can extract a KMZ's contents since it is a ZIP archive with a renamed extension

Command line GDAL/OGR's ogr2ogr reads and converts KMZ alongside plain KML

For archives

Prefer KMZ over bare KML for DAM archiving whenever the map includes overlay images, custom icons, or 3D models, since the zip packaging guarantees the KML and its assets stay together as one file through upload, versioning, and download. Keep the original KMZ intact rather than re-zipping it, and extract the internal doc.kml only for metadata indexing or preview rendering.

KMZ was introduced by Keyhole, Inc. alongside KML itself, as a compressed packaging format for distributing Google Earth content that includes more than plain placemark geometry — image overlays, custom icons, and 3D models. Following Google’s 2004 acquisition of Keyhole, KMZ became the standard way Google Earth content with embedded media is shared and downloaded.

A KMZ file is, mechanically, just a ZIP archive: open one with any unzip utility and, by convention, you’ll find a doc.kml file at the root plus a folder of the images, icons, and models that KML file references. That’s the entire trick of the format — instead of leaving those referenced assets as external files the way plain KML does, KMZ folds them into the same container so the map and its media can never be separated in transit.

doc.kml — the placemark, path, and style markup, conventionally at the archive root
images/ or files/ folder — ground-overlay textures and custom icon images
3D models — referenced model files used by some placemarks

For a DAM, KMZ is the more asset-management-friendly of the two Keyhole formats precisely because it solves the multi-file problem that plagues Shapefile and, in a milder way, image-referencing KML: one file in, one file out, with everything the map needs already inside it. A DAM can treat a KMZ exactly like any other single-file binary asset for storage and versioning, while still being able to peek inside the zip to extract the doc.kml for metadata indexing, geographic extent, and thumbnail generation.

This is also a useful pattern to point to when explaining to non-GIS users why some geospatial formats are painless in a DAM and others aren’t: KMZ and GeoPackage both solve the companion-file problem by containerizing everything into one file, while Shapefile solves nothing and simply expects the user to keep several files together by discipline.

Frequently asked

What's actually inside a KMZ file?

A KMZ file is simply a ZIP archive, renamed with a .kmz extension, that bundles a KML document with the resources it references. By convention the main file inside is called doc.kml (though any single .kml file works), sitting alongside folders of icons, ground-overlay images, and COLLADA (.dae) 3D models the placemarks point to via relative paths.

Can I just unzip a KMZ to get the KML back?

Yes. Because a KMZ is just a ZIP archive with a different extension, any standard unzip utility, or even a plain rename to .zip, opens it and extracts the doc.kml file along with its images, icons, and models intact. The extracted KML is fully valid on its own — you lose nothing except the single-file convenience, since references to the bundled images and models will point to files that must now travel alongside it rather than staying packaged together.

Why would a DAM prefer KMZ over plain KML?

KMZ bundles the KML with every image, icon, and model it depends on into one file, so the asset can't lose its supporting media the way a bare KML with external references can.

Does compressing a KML into KMZ lose any data?

No. KMZ uses standard ZIP (DEFLATE) compression, which is lossless by design — every byte of the original XML markup, coordinates, styles, and embedded image or model files is reconstructed exactly on extraction, with nothing approximated or discarded. The only things that change are file size, since XML text and images typically compress well, and packaging: KML and its assets move from separate files into one archive, but the underlying data stays bit-for-bit identical before and after.

Can Google Earth and QGIS both open KMZ files?

Yes. Google Earth Pro (desktop and web) opens KMZ natively as its home format, rendering placemarks, ground overlays, and 3D models directly. QGIS also opens KMZ, going through its GDAL/OGR-based vector providers — specifically the LIBKML driver — rather than a dedicated KMZ renderer. Because both applications ultimately read the same underlying KML markup and reference the same bundled images and models, a KMZ authored in one is generally readable in the other. The same GDAL/OGR stack that QGIS uses also powers command-line tools like ogrinfo and ogr2ogr for inspecting or converting KMZ without a GUI.

Is KMZ good for storing 3D models and image overlays in a DAM?

Yes — arguably that's exactly what KMZ was built for. Its ZIP wrapper lets a single asset carry COLLADA (.dae) 3D models, the ground-overlay images draped onto terrain, and the icons used for placemarks, all referenced by relative paths inside doc.kml. For a DAM, that means one KMZ upload equals one complete, self-contained geographic asset — there's no risk of a model or texture going missing because a linked file wasn't uploaded alongside the KML, as often happens with plain, unbundled KML.

How should a DAM generate a preview thumbnail for a KMZ asset?

By unzipping the archive, reading the internal doc.kml for the geometry and camera view, and rendering that with a tool like QGIS or a KML-aware library rather than trying to preview the zip file directly.

Can KMZ be converted to GeoJSON or GeoPackage?

Yes. GDAL's ogr2ogr command-line tool, using its LIBKML driver, reads KMZ directly (no need to unzip first) and converts it to GeoJSON, GeoPackage, Shapefile, or most other vector formats GDAL supports — for example, `ogr2ogr -f GeoJSON output.geojson input.kmz`. QGIS exposes the same conversion through its "Save As" and processing tools, since it's built on the same GDAL/OGR library underneath. Attribute data, geometry, and styling generally carry over, though some KML-specific features like network links or 3D models may not have a direct equivalent in the target format.

Sources

KMZ is a zipped KML plus referenced images, icons, and 3D models, developed by Keyhole Inc. checked 2026-08-07 — General KML/KMZ format references (Google Earth documentation ecosystem)
Keyhole, Inc. acquired by Google in 2004; KMZ became the standard shareable Google Earth package format checked 2026-08-07 — OGC KML standard page