Convert KMZ to Shapefile: check attributes and verify in QGIS

What can survive the conversion?

A KMZ is a container for KML and optional resources. Shapefile is a flat vector dataset with a separate DBF attribute table. Points, lines, polygons and supported scalar fields can transfer, but folders, balloon presentation, custom icons, overlays and 3D models do not become an equivalent Shapefile project.

An attribute displayed in a Google Earth balloon may be structured ExtendedData or just HTML inside Description. Those are different inputs. Do not assume a visually displayed table will become separate DBF columns. Inspect the KML or an intermediate GeoJSON to see which properties the reader exposes.

Plan a field mapping before export. DBF names are limited to 10 characters, so survey_year and long_field_name need shortened names; two long names can collide. Text has a fixed width, nested values do not have a native DBF representation, and a single Shapefile cannot mix geometry families. Keep identifiers short and stable, and retain a CSV or GeoPackage copy if your full schema matters.

Convert the KMZ and keep the complete ZIP

GeoConvert reads the root doc.kml when present, ignoring case; otherwise the archive must contain exactly one KML document. It validates every KML member but converts only the selected document. Extra KML files are not merged. Separate files or linked documents must be handled explicitly.

Use the downloadable synthetic-points.kmz for a controlled rehearsal. It contains two Point features at longitude/latitude [12,45] and [12.001,45.001], with Name, Description and three ExtendedData fields: site_code, survey_year and long_field_name. It is synthetic test data, not surveyed ground truth.

1. Open the KMZ to Shapefile tool linked on this page, add your KMZ, and select Shapefile output.
2. Keep WGS 84 / EPSG:4326 unless the recipient requests a specific projected CRS. KML coordinates already use WGS 84; changing a label is not reprojection.
3. Run the conversion and read every warning. If mixed geometry is rejected, separate points, lines and polygons in a GIS tool and export each family independently.
4. Download the ZIP and extract all sibling files into one folder. Keep their shared base name intact; do not send only the .shp.

Verify geometry, coordinates and attributes in QGIS

The automated Node WASM engine check for the supplied KMZ produced two points at the expected coordinates, but DBF contained only Name and Descriptio; site_code, survey_year and long_field_name were absent. The 452-byte KMZ produced a 738-byte Shapefile ZIP in that fixture run. These are measured results for this synthetic file and engine, not a guarantee for other data. The sample manifest records the inputs, outputs and inspection. The following is a repeatable desktop verification procedure. It does not claim that this article was manually tested in a particular QGIS release. Menu wording can vary; the essential checks are the layer source CRS, all feature records and their known locations.

The project CRS controls map display, while the layer CRS describes the stored numbers. QGIS can display a WGS 84 layer in a projected project through on-the-fly transformation. A visually plausible map is useful evidence, but it does not replace checking the source coordinates.

1. Drag the extracted .shp into QGIS. Open Layer Properties → Information or Source and confirm geometry type, feature count and the declared CRS.
2. Open the attribute table and clear any filters. For the supplied sample, check that there are two records, then compare Name and Descriptio with the sample manifest. The current engine does not retain the sample’s three ExtendedData fields in DBF; this is a limitation to detect, not an expected full-schema export.
3. Inspect the exported field names and types. Distinguish a renamed field from one that is absent: in the sample, survey_year and long_field_name are absent, rather than simply renamed. For your own data, record the actual field mapping; do not infer it from a truncation rule. Compare nulls, numeric precision, long text and non-ASCII strings in your own data.
4. Zoom to the layer and compare a known feature with a trusted reference. For the supplied WGS 84 sample, check longitude 12 and latitude 45 numerically; it is not intended to coincide with a real surveyed object.
5. For polygons, run QGIS Check validity and review invalid geometries before measuring or overlaying them. Compare the output extent and count with the source, and save the verification notes beside the ZIP.

If fields or features are missing

Convert the same KMZ to GeoJSON as a diagnostic intermediate. If a field is absent there, it was not exposed by the KML reader, so Shapefile export cannot restore it. If it exists in GeoJSON but changes in DBF, investigate name truncation, field width, type conversion or encoding.

For a rich description table, create a deliberate extraction and field-mapping workflow in desktop GIS or a script rather than relying on a converter to infer HTML semantics. For large schemas or exact field names, use GeoPackage or retain GeoJSON when the recipient accepts them.

Unexpected feature counts can also indicate that the archive contains multiple KML documents, multiple folders or unsupported features. Count actual convertible geometries rather than all XML Placemark elements; a Placemark can lack geometry or contain a collection.

A practical delivery checklist

Keep the original KMZ, the full Shapefile ZIP, a source-to-output field map and a short verification record. Note the source CRS, output CRS, feature count, extent, geometry family and any conversion warnings. Treat changed names or clipped values as explicit data changes.

If names must be preserved exactly or the dataset contains mixed geometry and complex properties, request a different delivery format. Packaging the ZIP correctly fixes missing sidecars; it does not remove the format limits of Shapefile.