KML to GeoJSON Converter

Convert KML files from Google Earth to GeoJSON format for web mapping and GIS applications.

Skip to the tool

KML is the format Google Earth, My Maps, and most consumer GPS exports use. GeoJSON is what every modern web mapping library — Leaflet, Mapbox GL, MapLibre, OpenLayers, deck.gl — speaks natively. The conversion isn't lossless in both directions, but for the majority of KML in the wild (Placemarks, LineStrings, Polygons, ExtendedData) it's a clean structural translation.

Paste your KML or upload a .kml/.kmz file on the left. The converter parses the XML, walks every <Placemark>, maps geometries to their GeoJSON equivalents, and lifts <ExtendedData> entries into the resulting Feature's properties. The output appears on the right ready to copy or download.

Below the converter, the body covers the parts that aren't one-to-one: KML's styling tags (<Style>, <StyleMap>) drop on the floor because GeoJSON has no styling vocabulary, altitude is preserved as the third coordinate position, and KMZ archives are unzipped first. For round-tripping back to KML, see the GeoJSON to KML converter.

Converting KML to GeoJSON

This tool parses KML (Keyhole Markup Language) data and converts it to GeoJSON format. KML Placemarks become GeoJSON Features, and KML geometry elements (Point, LineString, Polygon, MultiGeometry) are mapped to their GeoJSON equivalents.

Simply paste your KML content into the input panel. The converted GeoJSON is displayed in the result panel and visualized on the map.

KML<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <Placemark>
    <name>Empire State Building</name>
    <Point>
      <coordinates>-73.9857,40.7484,0</coordinates>
    </Point>
  </Placemark>
</kml>

What Gets Converted

  • Placemarks — converted to GeoJSON Features with geometry and properties
  • Coordinates — reordered from KML's lon,lat,alt to GeoJSON's [lon, lat] array format
  • Names and descriptions — preserved as Feature properties
  • MultiGeometry — converted to appropriate Multi-type GeoJSON geometries
  • ExtendedData — included in Feature properties when available

Limitations

KML features that do not have direct GeoJSON equivalents are not converted:

  • Styling information (colors, icons, line widths) — GeoJSON has no built-in styling
  • Ground overlays and screen overlays — image-based features
  • 3D altitude data — GeoJSON supports elevation but many consumers ignore it
  • Network links and dynamic content — GeoJSON is a static format

To convert in the other direction, use the GeoJSON to KML converter.

Try It

Paste this KML containing a Placemark for the Sydney Opera House. The converter produces a GeoJSON Feature with the name preserved as a property:

KML<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <Document>
    <Placemark>
      <name>Sydney Opera House</name>
      <description>Iconic performing arts venue</description>
      <Point>
        <coordinates>151.2153,-33.8568,0</coordinates>
      </Point>
    </Placemark>
  </Document>
</kml>

The resulting GeoJSON output:

GeoJSON{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {
        "name": "Sydney Opera House",
        "description": "Iconic performing arts venue"
      },
      "geometry": {
        "type": "Point",
        "coordinates": [151.2153, -33.8568]
      }
    }
  ]
}

The altitude value (0) is dropped since the GeoJSON output uses 2D coordinates. The KML <name> and <description>elements become properties on the Feature.

How the Conversion Algorithm Works

The converter parses the KML XML document and extracts every Placemark element. Each Placemark's geometry is read from its child element (Point, LineString, Polygon, or MultiGeometry) and converted to the equivalent GeoJSON geometry type. KML coordinate strings (lon,lat,alt) are split and restructured into JSON arrays.

After conversion, you can view the result on a map, validate it against RFC 7946, or process it with any of the other GeoJSON tools. For more on the GeoJSON format and its rules, see the GeoJSON Specification Guide.

KMZ Archives and Multi-Document Files

KMZ files are simply ZIP archives containing one or more KML documents and any referenced assets (icons, ground overlays, models). When you upload a .kmz, this tool unzips the archive in your browser, locates doc.kml (or the first.kml entry if that filename is absent), and runs the same converter against its contents. Any embedded images or models are discarded — GeoJSON has no equivalent structure for them.

KML documents that nest <Folder> elements (the way My Maps groups layers) are flattened: every Placemark, regardless of folder depth, ends up as a sibling Feature in the output FeatureCollection. The original folder name is preserved on each Feature in a folder property so you can re-group later. Multi-document KML files (<Document> nested inside another <Document>) are similarly flattened.

Common Gotchas When Migrating from KML

  • Coordinate order in KML is lon,lat,alt as a comma-separated string with no whitespace inside a coordinate triple. Multiple coordinates are separated by whitespace, not commas. The converter parses both styles you'll see in the wild, but if you're hand-editing KML by hand, this is the rule.
  • Altitude is the third coordinate position in KML and is preserved in GeoJSON output as a third element when present. Most web maps ignore the altitude; PostGIS and CesiumJS will use it. RFC 7946 explicitly permits 3D coordinates but warns that consuming applications may discard them.
  • Polygon rings in KML use <outerBoundaryIs> and <innerBoundaryIs>. The converter maps these to GeoJSON's outer-then-inner ring array convention. KML doesn't enforce winding order; the output is rewound to RFC 7946's right-hand rule (exterior CCW, holes CW).
  • Time-stamped placemarks (<TimeStamp>, <TimeSpan>) are extracted into start and end properties as ISO 8601 strings — useful for tools like kepler.gl that animate features along a time axis.
  • Styling tags drop on the floor. <Style>, <StyleMap>, and inline <styleUrl> references don't survive the conversion because GeoJSON has no styling vocabulary. If you need to preserve styling, encode it as properties (fill-color, stroke-width) and apply it client-side with simplestyle-spec or your mapping library's own styling pass.