All tools
Format conversionLocal browser worker

KML to GeoJSON Converter

Convert KML placemarks and ExtendedData to GeoJSON locally, with explicit reports for flattened folders, styles, and unsupported KML semantics.

Loading tool

Preparing this tool in your browser.

Preparing the local tool…

Format preservation contract

This is the converter's static format contract. The result report adds input-specific warnings, field mappings, transformations, and losses for each run.

Data areaStatusBehavior
GeometryConditionalPlacemark point, line, polygon, multipart, geometry-collection, and null geometry are normalized to GeoJSON; open rings are closed, while KML altitude and extrusion semantics are reported and omitted.
AttributesTransformedPlacemark metadata and ExtendedData become GeoJSON properties; schema-typed values are normalized to their source text.
Coordinate reference systemPreservedKML WGS84 longitude/latitude coordinates remain RFC 7946 longitude/latitude coordinates without reprojection.
DimensionsPreservedObserved XY and XYZ coordinate positions remain in GeoJSON.
LayersTransformedKML Folder hierarchy and folder metadata are reported and flattened into one GeoJSON FeatureCollection.
StylesTransformedSupported referenced KML style values become ordinary GeoJSON properties; reusable KML style structure is not retained.
AttachmentsNot supportedNetwork links, overlays, models, and packaged attachments are rejected rather than fetched or silently omitted.
PackagingPreservedOutput is a standalone UTF-8 GeoJSON document.

Convert KML placemarks to GeoJSON

Paste or drop a standalone KML 2.2 document and download one RFC 7946 GeoJSON FeatureCollection. Placemark geometry becomes GeoJSON geometry, KML feature metadata and ExtendedData become properties, and placemark IDs remain feature IDs. A second download records every format-specific transformation or omission.

The conversion runs in a dedicated browser worker. It does not fetch linked resources, upload the KML, or send feature values and filenames to analytics.

Worked example

Input:

<kml xmlns="http://www.opengis.net/kml/2.2">
  <Document>
    <Placemark id="parcel-7">
      <name>North field</name>
      <ExtendedData>
        <Data name="score"><value>0.92</value></Data>
      </ExtendedData>
      <Point><coordinates>12.55,55.68</coordinates></Point>
    </Placemark>
  </Document>
</kml>

Output:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "id": "parcel-7",
      "properties": { "name": "North field", "score": "0.92" },
      "geometry": { "type": "Point", "coordinates": [12.55, 55.68] }
    }
  ]
}

KML ExtendedData is text-oriented, so score remains the string "0.92" rather than being guessed as a number.

Input-specific considerations

Input must be well-formed XML with an unprefixed kml root in the OGC KML 2.2 namespace. DTD and entity declarations are rejected before parsing. Network links, ground, photo, and screen overlays, and model geometry are also rejected rather than fetched or silently represented as ordinary features. This release accepts standalone .kml documents, not KMZ archives.

Point, line, polygon, multipart, and geometry-collection data are normalized to GeoJSON. A placemark without geometry remains a feature with null geometry. XY and XYZ coordinate positions remain in WGS 84 longitude/latitude order without reprojection. Open polygon rings are closed and reported. KML tracks, altitude-mode, extrusion, and tessellation semantics are not supported in this release; tracks are rejected, while the other semantics are omitted with report entries.

Placemark metadata, ExtendedData, and supported referenced style values become ordinary GeoJSON properties. SchemaData values are normalized to their source text so the converter does not guess types. Reusable KML style structure does not survive as a GeoJSON style model. Folder hierarchy and folder metadata are flattened into one FeatureCollection, while camera, look-at, and region metadata are omitted; each applicable change appears in the conversion report.

Limits and privacy

These values are the effective central browser-worker limits for this page:

Runtime limitExact value
Input size (maxInputBytes)26214400 bytes (25 MiB)
Features (maxFeatures)25000
Coordinate positions (maxCoordinatePositions)2000000
Property fields (maxPropertyFields)2048
Serialized properties (maxPropertyBytes)16777216 bytes (16 MiB)
XML/property nesting (maxNestingDepth)64 levels
Hard timeout (timeoutMs)60000 ms (60 seconds)

Files, attributes, coordinates, and filenames are never uploaded or included in analytics.

Use GeoJSON to KML for the reverse direction, then run the GeoJSON Validator when a downstream system has stricter geometry expectations. WKT to KML handles one text geometry, while Shapefile to KMZ handles a zipped Shapefile dataset. See the GIS-ready export workflow for broader downstream guidance.

FAQ

Does this upload my KML?

No. XML parsing, normalization, GeoJSON serialization, and report generation happen in a dedicated browser worker on your device.

No. NetworkLink, GroundOverlay, PhotoOverlay, ScreenOverlay, and Model content is rejected. The converter never fetches external KML resources.

Are KML folders preserved as GeoJSON layers?

No. GeoJSON FeatureCollection has no KML folder hierarchy. Features are flattened into one collection, and the report identifies that transformation.

What happens to KML styles and ExtendedData?

ExtendedData and supported referenced style values become GeoJSON properties. Reusable style definitions are not preserved as a GeoJSON style system, and SchemaData values remain source text instead of being type-guessed.

Does the converter reproject KML coordinates?

No. KML and RFC 7946 GeoJSON both use WGS 84 longitude/latitude coordinates for this workflow. XY and XYZ positions pass through without reprojection.

Related tools