KMZ to Shapefile Converter: Google Earth into GIS

Heading to the field? Install this site from your browser menu and this tool works with no signal. See how

How to use this tool

Drop a KMZ on the panel above. It is unzipped in the browser, the KML inside is parsed, and the features are drawn on the map so you can check them before converting. Press Convert to shapefile and download, and you get a zip holding the .shp, .shx, .dbf and .prj.

If the file holds more than one geometry type, the conversion stops and explains why. That is the single most common outcome with real Google Earth files, and the section below explains what to do about it.

If you have a plain .kml rather than a .kmz, use the KML to Shapefile Converter instead. Same engine, same output, it just skips the unzip step.

What is inside a KMZ, and what makes it across

A KMZ is a zip. Open one and you typically find doc.kml in the root, plus a files folder holding icon images, ground overlay photographs and legend graphics. The geometry and the attributes are all in the KML. Everything else is presentation.

Only the KML crosses over. Icons, overlays and legends have no home in a shapefile and are discarded. That is not a limitation of this tool, it is the format: a shapefile stores geometry and a table, and nothing else.

One detail worth knowing. The specification allows a KMZ to contain several KML files, and does not say which one is the map. The convention, which this tool follows, is that a file named doc.kml in the archive root wins, falling back to the first KML found anywhere. If you have a KMZ with several KMLs and the wrong one is being read, unzip it and convert the one you want directly.

Why one KMZ usually becomes three shapefiles

The shape type in a shapefile is written once, in the header of the .shp, and it applies to every record in the file. Type 1 is a point, type 3 is a polyline, type 5 is a polygon. There is no type that means a mixture, and there is no way to override it record by record.

So a Google Earth file with boreholes, access tracks and a permit boundary in it cannot become one shapefile. It has to become three, each with its own .shp, .shx, .dbf and .prj, which is twelve files in total. Any converter that appears to produce one file from mixed input is discarding everything that does not match the first shape it found.

This tool refuses the conversion instead, and names the problem. The fix takes two minutes: in Google Earth, sort the placemarks into folders by type, right click each folder, save it as its own KMZ, and convert them one at a time.

Attribute tables complicate this slightly, because each of the three outputs gets its own table containing only the columns its features carried. If your points have a depth column and your polygons do not, the polygon shapefile will not have that column at all. That is correct behaviour, but it surprises people expecting one consistent schema.

A worked check you can repeat on paper

You can confirm the shape type rule yourself with any hex viewer, and it is worth doing once because it makes the constraint concrete rather than something a tool told you.

Unzip the shapefile this tool produces and open the .shp. The header is 100 bytes long. The first four bytes are the file code, always 9994, written most significant byte first, which is unusual. Bytes 24 to 27 hold the file length in 16 bit words, also most significant byte first. Then at byte offset 32, written the other way round with the least significant byte first, sits a single 32 bit integer: the shape type for the entire file.

• Read 1 at offset 32 and every record in that file is a point.
• Read 3 and every record is a polyline.
• Read 5 and every record is a polygon.

There is nowhere else in the format where a shape type appears per record, which is what makes the restriction absolute. The mixed endianness in that same 100 byte header, big endian for the file code and length, little endian for everything after it, is a genuine quirk of the specification and a reliable source of bugs in anything that reads it by hand.

How this was checked

The shapefile writer was built twice, once for the browser and once independently under Node, and the two are compared automatically. Files produced here are then opened by a third party shapefile library sharing no code with either, so an error would have to be made identically in three places to go unnoticed.

The full loop is tested: a shapefile in UTM zone 12N is converted to KMZ, the KMZ is fed back through this page, and the resulting shapefile is opened by the third party reader. Positions return to their starting coordinates within 2.3 nanodegrees and every attribute value survives intact.

One finding came out of that cross checking rather than being assumed. Shapefile winds the outer ring of a polygon clockwise and its holes counter clockwise, and GeoJSON requires exactly the opposite. Our reader and the third party reader initially disagreed for that reason. Ours follows the GeoJSON specification and reproduces the original ring vertex for vertex, and there is now a permanent test holding it there.

Mistakes that catch people out

Renaming a KMZ to .kml and expecting it to work. The extension is not the format. A KMZ is compressed binary, and a text parser fed one sees rubbish. Rename it to .zip and extract it if you want the KML inside.

Expecting ground overlays to convert. A georeferenced image draped over the terrain is not vector data and has no shapefile equivalent. Extract it from the archive and georeference it separately as a raster.

Losing the folder structure without noticing. Folders in Google Earth often carry meaning, usually a phase or a contractor. A shapefile has no folders, so this tool writes the full folder path into an attribute column. Check that column exists before you throw the KMZ away.

Assuming the attribute names survived. The .dbf caps column names at ten characters, a limit inherited from dBase in 1983. Anything longer is cut, and two names that shorten to the same ten characters get a digit appended to the second.

Trusting a converter that never complains. If you feed mixed geometry into a tool and it hands back a single shapefile without a word, check the feature count. It has almost certainly dropped everything that did not match the first shape type it encountered.

Related Calculators and Reference

Bringing Google Earth data into GIS is usually the start of a job rather than the end of one.

• KML and KMZ Viewer for looking inside the KMZ first, including folder paths and attributes, before committing to a conversion.
• KML to Shapefile Converter for the same conversion when you have a plain .kml rather than a compressed .kmz.
• Shapefile to KMZ Converter for the return journey, sending GIS results back out to people without GIS software.
• Coordinate Converter, latitude and longitude to UTM for turning the converted positions into grid coordinates for setting out.
• CSV Cleaner for XYZ data for cleaning the attribute table this tool exports.
• The Esri Shapefile Technical Description documents the 100 byte header and shape type field described above.