KMZ vs KML vs Shapefile: Which Format Should You Actually Use?

Three files land in your email. One ends in .kmz, one in .kml, and one is actually a .zip containing four different files with the same name but different extensions. All three are geographic data. All three are common. And the differences between them are not obvious if nobody has ever explained them to you.

Here's the comparison, in plain terms.

Quick reference

The short version: KML and KMZ are Google Earth's world, Shapefile is the professional GIS world, and if you're building for the web you probably want neither (more on that below).

KML: when readability matters

KML is a text format. Open any .kml file in a plain text editor and you'll see XML that describes your entries in a way a patient human can read. Coordinates, names, descriptions, line colors, all written out as text.

That readability is the main thing KML has going for it beyond Google Earth compatibility. It means:

• You can edit a label or fix a coordinate by hand without needing any software.
• It works with version control (if you track files in Git, text files have meaningful history; binary files don't).
• You can search through a KML for a specific name or property with a basic text search.
• It's easier to spot problems: a typo in a coordinate, a broken description, an entry that should have been deleted.

KML is also the format that Google Earth, Google My Maps, and most consumer mapping tools export when you ask them to save a file. If somebody sends you a file they exported from Google Earth, it's probably KML.

The limitation is file size. KML is verbose. A hundred entries might produce a file that's ten times larger than the same data stored as binary. For large datasets this matters. For a dozen fields or a property boundary, it doesn't.

Use KML when: you want something you can read and edit, file size isn't an issue, and you're working in Google Earth or sharing with someone who is. More detail on KML and its relationship to KMZ is in our dedicated comparison.

KMZ: when you have photos or need a smaller file

KMZ is a zip archive with a KML inside. On its own that's not a major advantage over just sending the KML, but KMZ adds two things:

File compression. XML compresses extremely well, often down to 5 to 10 percent of the original size. A 10 MB KML becomes a 700 KB KMZ. For email or downloads, that's a meaningful difference.

Bundled photos. A KMZ can include image files alongside the KML, which means when you click a marker in Google Earth the photo is right there, embedded in the same file you received. This is what makes KMZ the default export format for field mapping apps like Landplot. You walk a site, take photos at key points, export, and the entire record (locations, outlines, photos) ships as one file.

This bundling is what sets KMZ apart from KML in a real workflow. If your data has associated photos that should travel with the map entries, KMZ is the right format. If it doesn't, KML and KMZ are functionally identical, and KMZ just saves you some bytes.

The downside of KMZ: it's opaque. You can't read or edit it without unzipping it first, and most people don't do that. It's a delivery format, not an editing format.

Use KMZ when: you have photos attached to entries, you're emailing or sharing the file and want it small, or you want one clean file rather than a folder of pieces. If you're using a GPS field mapping app like Landplot, KMZ is the right export choice whenever photos are involved.

Shapefile: when the GIS world expects it

Shapefile is a format from 1993 that became the standard for professional geographic data exchange and never really gave up the title. State agencies, federal open-data portals, engineering firms, surveying companies, and universities almost all either produce or accept Shapefiles. It's the lingua franca of the industry.

The format is unusual because a single "Shapefile" is actually a collection of three to seven files that must stay together and share the same base name. The .shp holds the actual geometry. The .dbf holds the properties (names, IDs, measurements). The .prj holds the coordinate system information. The rest are indexes and metadata. If you receive a Shapefile as a zip, don't just extract the .shp and expect it to work.

Shapefile also has one well-known limitation: property names are capped at 10 characters. So population_count becomes population or populat_1. It's an artifact of the format's 1990s design and there's no fix for it. You just have to know it's there.

Despite those quirks, Shapefile is what you use when:

You're sending data to a government agency or enterprise GIS team. These workflows are built around Shapefile. Sending them GeoJSON or KML might force them to convert it, which introduces friction and sometimes errors. Just send what they expect.

Your recipient uses QGIS, ArcGIS, AutoCAD Map, or MapInfo. Desktop GIS tools load Shapefiles natively, without prompting, without conversion. It's the default import format in most of them.

The dataset is large. Binary formats are smaller than text formats for the same data. A 200 MB GeoJSON might be 50 MB as a Shapefile, and for large datasets that difference matters for how fast tools can load and process the file.

Use Shapefile when: you're working with or for professional GIS users, government systems, or anyone who's likely to open the file in QGIS or ArcGIS. If you're not sure, ask your recipient what format they want. Shapefile is the most likely answer. More on the Shapefile vs GeoJSON comparison is in a separate article.

What about GeoJSON?

GeoJSON isn't one of the three this article is comparing, but it's the format you'll encounter when any of the three get used in a web context, so it's worth naming.

GeoJSON is the native format for web maps. Browser-based mapping libraries like Leaflet, MapLibre, and Mapbox read it directly, without any conversion layer. APIs that return geographic data return GeoJSON. Databases like Postgres and Supabase have built-in GeoJSON support. If you're building anything web-facing, GeoJSON is the format you end up with.

The trade-off: GeoJSON is text (like KML), which means it can be large for big datasets. It also officially only supports WGS 84 coordinates (the standard GPS coordinate system), so if you're working with local coordinate projections you'll need Shapefile or KMZ.

For day-to-day fieldwork, documentation, and site records, the three formats above are the ones you'll encounter. GeoJSON lives on the other side of the conversion step when data heads to the web.

Which one should you use?

Start with these questions:

Are you working with Google Earth or sharing with someone who is? KML or KMZ. Use KMZ if photos are involved, KML if not.

Are you sending to a GIS professional, a government agency, or any organization running desktop GIS software? Shapefile. Ask first if you're unsure, but Shapefile is the safe bet.

Do you need a smaller file or have images to bundle in? KMZ over KML.

Are you loading the data into a web map or handing it to a developer? Convert to GeoJSON first. Georaf does that in one step.

Do you need to read or edit the file yourself? KML. It's the only one of the three you can open in a text editor.

In practice, most workflows involve more than one of these formats at different stages. You might collect data in the field as KMZ (with photos), convert to Shapefile for a government submission, and convert again to GeoJSON when the data goes on a website. Georaf converts between all of them, in any direction, with a quality check on the way through.

Converting between them

Every common tool handles conversion between these three formats:

Georaf: drop any of them on georaf.com and pick the output. KMZ doesn't need to be unzipped first. The converter also checks the data for problems (broken geometry, missing coordinate system declarations, entries that won't load in other tools) and lets you fix them before downloading.

QGIS: open any of the three and export to any other. Free, open source, runs on every platform.

ogr2ogr (command line): the most flexible option if you're comfortable in a terminal. Handles every format here in a one-liner.

ogr2ogr -f "ESRI Shapefile" output_folder/ input.kml
ogr2ogr -f KML output.kml input.shp

The main conversion caveat to know: KML styling (line colors, icon choices, fill patterns) does not survive conversion to Shapefile or GeoJSON. The coordinates and properties come through cleanly. The visual presentation does not. If styling matters, keep the file as KML or KMZ.

Going from Shapefile to GeoJSON or KML, watch for the 10-character field-name truncation. A property called owner_name in Shapefile might arrive as owner_name in KML, but population_count will have been truncated to populatio_c on the way in. It's not fixable after the fact; you need the original source to know what the full names were.

The bottom line

KML and KMZ are for Google Earth and anything that lives in that ecosystem. Shapefile is for the professional GIS world. GeoJSON is for the web. The format you use on any given day depends entirely on who you're working with and where the data ends up.

If you're ever unsure, ask the recipient what format they want. Most people who regularly work with geographic data have a strong preference, and sending the wrong one guarantees a conversion step on their end.