How to Convert KML to GeoJSON: QGIS, ogr2ogr, and Browser Tools

Why this conversion matters

KML is the format every consumer mapping tool exports — Google Earth, Google MyMaps, drone flight planners, hiking apps. GeoJSON is the format every web map library reads natively. Bridging the two is one of the most common GIS conversions, and the one most prone to silently losing data if done wrong.

This guide covers the three reliable paths and what each loses.

Method 1: QGIS (no terminal required)

QGIS handles KML through the same OGR driver as everything else.

1. Drag the file onto the canvas. Drop the .kml (or .kmz — same driver) into the QGIS window. The Layers panel shows one entry per KML folder if the source uses them.
2. Right-click the layer → Export → Save Features As.
3. In the dialog: set Format → GeoJSON, CRS → EPSG:4326 (GeoJSON requires WGS 84), pick a path, click OK.
4. The new .geojson file appears in your output directory.

This is the most forgiving option. QGIS reads multi-layer KML, preserves ExtendedData attributes, and exposes layer options for coordinate precision and field renaming.

Gotcha: if the KML uses <gx:Track> GPS tracks, QGIS reads them as multi-line geometries with time and altitude as side columns. Some downstream viewers expect single LineStrings — split with the Vector → Geometry Tools → Multipart to Singleparts processing tool.

Method 2: ogr2ogr (the one-liner)

For batch jobs, automation, or scripting:

ogr2ogr -f GeoJSON out.geojson in.kml

That's the whole thing. GDAL handles KML and KMZ identically. Add -t_srs EPSG:4326 for safety — KML is already WGS 84 but the explicit flag costs nothing.

If the KML has multiple folders / layers:

ogrinfo -so in.kml

lists the layers. Then convert one:

ogr2ogr -f GeoJSON tracks.geojson in.kml "Tracks"

For KMZ (the zipped variant) GDAL transparently unpacks the archive. No extraction step needed.

Useful additions:

• -lco RFC7946=YES for strict RFC 7946 output (right-hand winding, antimeridian splitting).
• -lco COORDINATE_PRECISION=6 to truncate to ~10 cm precision and shrink the file.
• -dim XY if you don't need elevations (drops the Z dimension).

Method 3: browser tools

If you don't have QGIS or GDAL handy, some in-browser KML→GeoJSON converters run the conversion locally via WebAssembly — no upload, no server-side processing. GISpo's converter works differently: it runs on an isolated, short-lived GDAL worker (Fly.io, Frankfurt/EU), and your file is processed in a per-request temporary directory that is deleted in full immediately after the conversion finishes — no database, no persistent storage.

Limits to be aware of:

• File size ceilings (typically 50–200 MB depending on the tool).
• Fewer knobs than ogr2ogr — usually no precision control or layer selection.

For typical Google Earth exports, drone logs, or hiking traces this is the fastest path.

What gets lost in conversion

KML carries information GeoJSON cannot represent. The honest inventory:

• Styling. KML's <Style> elements (icon URLs, line colours, fill colours, label rules) drop entirely. GeoJSON has no styling spec; visual appearance is the consumer's job.
• Balloon HTML. KML descriptions can contain rich HTML. OGR preserves the description as a string property, but HTML rendering is up to the destination.
• Folder hierarchy. KML's nested folder structure flattens. OGR exposes folders as separate layers or as a Folder attribute — exact mapping depends on the file.
• NetworkLinks. KML can reference external resources via <NetworkLink>. These are not followed during conversion; if the source data lives in linked files, you need to fetch and convert each one.
• Models and ground overlays. <Model> (COLLADA references) and <GroundOverlay> (raster images) are not vector features and are dropped silently.
• Time semantics. <TimeStamp> and <TimeSpan> survive as text properties but lose their type — they're just strings on the GeoJSON side.

What survives

• All point, line, and polygon geometries including multi-geometries.
• Names and descriptions (mapped to name and description properties).
• ExtendedData fields (mapped to attribute columns).
• Coordinates and elevations (Z preserved in the array when present).

Common errors

• "Invalid coordinates" on import. Older Garmin and Lowrance exports sometimes include empty <coordinates> tags. Open the file in a text editor and delete the empty placemarks.
• Lat / lon swapped. Some authors accidentally write coordinates as lat,lon when KML requires lon,lat. The result is points in the wrong continent. Inspect a few coordinates in a text editor and confirm the order.
• Cyrillic or CJK garbled. KML is UTF-8 by spec, but old tools sometimes write Windows-1252. If you see mojibake, open the source in an editor that detects encodings and re-save as UTF-8.
• Empty FeatureCollection. Probably the KML uses NetworkLinks or contains only Models / overlays. ogrinfo is the diagnostic.
• Uploaded KMZ when the tool wanted KML. Rename .kmz to .zip, extract, find doc.kml, upload that.

Recommendation

For one-off conversions: a browser-based converter. For repeatable work or anything with multi-layer / multi-folder structure: ogr2ogr. For exploratory analysis where you'll style and re-export anyway: QGIS.