Convert KML to GeoJSON: 3 Ways, No GIS Knowledge Needed

You have a KML file. Maybe it came out of Google Earth, maybe a colleague exported it from a mapping tool you've never heard of. Now you need it as GeoJSON, because the library you're using doesn't read KML, or the API you're sending it to wants GeoJSON, or you just want it open in a format that actually plays nicely with modern tools.

Good news: it's a five-second job. The hard part is knowing which path to take, because there are three real options and the right one depends on whether you do this once a month or three hundred times a day.

This post walks through all three, with the trade-offs spelled out. No GIS background needed.

What's the actual difference between KML and GeoJSON?

Both formats describe the same thing: points, lines, and outlines on a map, plus whatever properties you want to attach to them (a name, a category, a population number, whatever).

KML is XML-based. Google Earth made it popular in the mid-2000s. It supports rich styling baked into the file itself, things like icon images, line colors, and 3D extrusions. Filenames end in .kml for the raw XML or .kmz for a zipped bundle (the zip can also include images and other assets).

GeoJSON is JSON-based. It's simpler. It does not carry styling, just the geometry and the data attached to each entry. Filenames end in .geojson or .json. It became the de facto interchange format on the web because every JavaScript mapping library reads it natively.

The geometry survives the conversion. The styling does not. That's the only thing you'll lose: line colors, icon images, label formatting. Everything substantive (coordinates, properties, names, descriptions) comes through intact.

Method 1: A one-click web converter

The fastest option if you're not living in a terminal every day.

1. Open the Georaf converter.
2. Drag your .kml or .kmz onto the upload zone.
3. Pick GeoJSON as the output.
4. Click Convert. Wait a few seconds. Download.

That's it. No installs. No command-line. Works on phones too.

The reason to use a web converter (any web converter, not just ours) for a one-off job is that the work to install something locally is almost always greater than the value you get from doing one file. Even if you're a developer.

The reason to use ours specifically is the quality score it generates alongside the conversion. KML files in the wild are often slightly broken: outlines that don't close cleanly, geometry that fails strict validity checks, entries with no coordinates. Most converters silently pass these through. We surface them and offer a one-click fix.

If you convert files occasionally, this is the path to use. The other two methods exist for people who need to automate the conversion as part of a script or pipeline.

Method 2: ogr2ogr (command-line, the workhorse)

If you're going to convert hundreds of files, or you want to script it, ogr2ogr is the answer. It's the conversion tool that ships with GDAL, the same engine that powers QGIS and most other open-source GIS tools.

Install it (Mac with Homebrew, Linux with apt, Windows via the GDAL binaries):

brew install gdal
# or
sudo apt install gdal-bin

Then run:

ogr2ogr -f GeoJSON output.geojson input.kml

That's the whole command. -f GeoJSON says what format you want out. The two filenames are output first, then input (a quirk of the tool, easy to get wrong on your first try).

For a .kmz you don't even need to unzip it first:

ogr2ogr -f GeoJSON output.geojson input.kmz

GDAL handles the unzip internally.

What it's good at: batch processing, automation, scripting. You can convert a folder of 500 files with a one-line shell loop. It's also genuinely thorough. It will preserve every property field and handle weird edge cases that simpler tools choke on.

What it's not good at: showing you what's actually in the file. If something fails, you get a terse error and you're on your own to figure out why. There's no preview, no quality report, no "this entry is broken" message in plain English.

Worth knowing: if the KML file is missing a coordinate system declaration (some hand-written KML omits it), ogr2ogr will assume WGS 84. That's almost always the right guess, but if your KML was generated from a local projection and somehow lost the declaration, you'll end up with data in the wrong place.

Method 3: Python with geopandas

If your conversion is one step in a larger data pipeline, doing it in Python keeps everything in one place.

import geopandas as gpd

# Read the KML
gdf = gpd.read_file('input.kml', driver='KML')

# Do whatever transformations you want
# gdf = gdf[gdf['name'].str.startswith('Site_')]

# Write out as GeoJSON
gdf.to_file('output.geojson', driver='GeoJSON')

Three lines, plus a setup step (pip install geopandas). Under the hood it's still using GDAL, so you get the same robustness as ogr2ogr, but with the full Python ecosystem around it: filter rows with pandas, join with other datasets, run validity checks, push to a database.

KML support is technically optional in geopandas' default install, depending on your version. If read_file complains, you may need to enable the KML driver explicitly:

import fiona
fiona.drvsupport.supported_drivers['KML'] = 'rw'

This is annoying but a one-time thing.

What it's good at: data pipelines, anything where conversion is a step in a longer workflow, any case where you also need to clean or transform the data on the way through.

What it's not good at: speed, for a single file. Spinning up Python plus geopandas for one conversion is overkill. Use Method 1 instead.

So which one?

The honest answer is that for 80% of people who Google "convert KML to GeoJSON," Method 1 is right, because they have one file and a deadline, and the time spent installing GDAL is bigger than the time saved.

The 20% who are scripting or automating know who they are.

A few things that can go wrong

The KML has no entries inside. Some KML files are valid XML but contain only styling definitions, no actual map data. The conversion will produce an empty GeoJSON. Open the source in Google Earth first to check there's something to convert.

The coordinates show up in the ocean. This means the KML had a coordinate system that wasn't WGS 84, and the conversion didn't catch it. See our piece on coordinate systems for why this happens and how to fix it.

The output file is huge. GeoJSON without compression can be significantly larger than the KML it came from, especially for files with detailed boundaries. If size matters, consider compressing the output (.geojson.gz) or using a tile-based format instead.

Properties got mangled. KML's <ExtendedData> is where most properties live. Different tools convert it differently. If you're missing fields after the conversion, the source file probably stashed them somewhere non-standard. Open the KML in a text editor and search for the missing field name to see where it actually lives.

Wrapping up

Conversion is the boring part. The interesting question is what you do with the data once you've got it in a format your tools speak. If you also need to validate, fix, or visualize the result, Georaf does all three on the same upload, without making you learn anything new.

If you're scripting it from code, our API does the same thing as the website over REST, with the same quality checks and auto-fix endpoints.

Either way, pick the option that fits how you actually work today, not the one that sounds most professional.