How to convert KML to GeoJSON
- Drop the .kml file into the converter box above.
- Check the features on the preview map; folders and placemarks are read for you.
- Choose GeoJSON and convert; the output is in WGS84, ready for a web map.
What changes when you convert KML to GeoJSON
| What | KML → GeoJSON | |
|---|---|---|
| Geometry | Kept | Points, lines and polygons are preserved exactly, including multi-part shapes. |
| Attributes | Kept | Every column and full field name moves from KML into GeoJSON untouched. |
| Styling & labels | Dropped | KML colors, icons and description balloons are presentation, not data. GeoJSON stores the underlying features, so styling is dropped (the geometry and attributes remain). |
| Coordinate system | Kept | Both formats are fixed to WGS84 longitude/latitude (EPSG:4326), so the coordinates are copied across without any reprojection. |
| Elevation (Z) | Kept | 3D Z values carry from KML into GeoJSON wherever the source records them. |
| File structure | Kept | A single, self-contained .geojson file you can move around on its own. |
Why convert KML to GeoJSON?
KML is what Google Earth and Google Maps produce, so field data, placemarks and drawn paths often start life there, while GeoJSON is what the web-mapping stack reads. Both sit in WGS84 longitude and latitude, so no reprojection is involved; the conversion rewrites placemarks as features whose properties Leaflet, Mapbox GL and OpenLayers can query, filter and style in code.
Coordinate system handling
Both ends of this conversion are nailed to the same datum, which turns the coordinate step into a straight copy: a position in the KML appears in the GeoJSON to the same digit, with nothing recalculated in between. The match extends to axis order, since KML already writes longitude ahead of latitude, so not even a swap is involved.
RFC 7946 settled the output question by deleting the crs member that older GeoJSON drafts carried, so the file cannot name an EPSG code even when a workflow wants one. Anything downstream that runs in Web Mercator, a vector tile pipeline for instance, performs its own projection at render or tiling time rather than asking the file.
What to check when converting KML to GeoJSON
Icon colors, line widths and balloon HTML do not travel, because GeoJSON under RFC 7946 has no styling model. Set the appearance in your map code, for example a Leaflet or Mapbox style driven by a property value, and confirm beforehand that the property names you need are present in the output, since that is where web libraries read attribute data.
Troubleshooting KML to GeoJSON
- A path drawn above the terrain loads at the wrong height. KML states how a height should be read through altitudeMode, and GeoJSON has no field for that instruction, so a viewer that honors third values treats them as absolute. Bake the terrain elevation into the numbers, or set the height handling in the renderer, Cesium for example.
- Style callbacks misfire on placemarks that held several shapes. A placemark built from MultiGeometry becomes one feature whose geometry is a collection, and code that switches on Point or LineString meets GeometryCollection instead. Split such placemarks in Google Earth beforehand, or branch on the collection and walk its parts.
- A polygon fills the entire globe in d3. d3-geo reads spherical winding order, and Google Earth happily saves rings drawn clockwise, which d3 takes as a shape containing the rest of the world. Run the layer through a rewind step, turf rewind or mapshaper both do it, and the fill snaps back to the parcel.
- Code reading the same property works on some features and crashes on others. KML never forces placemarks to share fields, so the features come out ragged, with keys present on one and absent from the next. Null-check each property in code, or normalize the fields in Google Earth first so every feature answers the same questions.
- A layer that is live in Google Earth converts to an empty collection. A KML built around a NetworkLink holds an address instead of geometry, and the features it displays are fetched from a server each time Earth opens it. Let Earth load the link, save the layer back out as a plain KML with the features embedded, and convert that saved copy.
About the formats
Most KML starts life in Google Earth, where placemarks and paths get drawn by hand or exported from a shared map, and GeoJSON is where that same geometry becomes web-ready. Converting here strips the Google Earth styling wrapper and hands you clean features that Leaflet, Mapbox GL or OpenLayers can render straight away. You draw once in Earth and then convert so the data drops into a slippy map or an API response.
Frequently asked questions
Why do the coordinates look reversed in the GeoJSON output?
GeoJSON stores longitude before latitude, so the order is correct by the specification rather than a fault. Web libraries that read GeoJSON expect exactly that arrangement.
Will Leaflet use the altitude value stored in my placemarks?
No. The Z value is kept in the position array, since the specification allows a third element, but many web renderers ignore it and plot the point in 2D.
Can I convert a zipped KMZ file the same way?
Yes. Use KMZ to GeoJSON, which unpacks the archive in the browser before translating, so the zipped file needs no manual extraction.
Does KML to GeoJSON keep my placemark names and descriptions?
Yes. Names, descriptions and other placemark data become feature properties, which is exactly where Leaflet and Mapbox look for attribute values. Folder structure flattens into a single FeatureCollection along the way.
Is a browser conversion still sensible for a huge KML?
A single large file converts fine, since the work happens in your tab's memory rather than against an upload cap, though the biggest documents make the tab pause while they parse. Recurring bulk jobs are a different matter, and a folder of exports on a schedule is better served by ogr2ogr in a script than by any page.
What does one placemark turn into on the JSON side?
A placemark named Well 3 at a single point becomes one object in the features array: its geometry holds the type Point with the same two coordinates, and its properties carry the label under the name key alongside whatever description the balloon held. Reading the first feature in the output is the fastest way to confirm the mapping.
Related converters
Ready to convert?
Drop a file and download the result in seconds. Nothing is uploaded, nothing is stored.