How to Convert KML to GeoJSON for Web Maps
Someone sent you a KML file — most often drawn by hand in Google Earth. Now you need that same data on a web map, and web maps speak GeoJSON. The shapes look simple: a few pins, a path, a shaded area. But KML holds more than shapes. It holds styles, notes, and folders, and you should know what carries over and what does not before you convert.
This guide uses the KML to GeoJSON tool on the home page and a small worked example: a walking tour with three stops, one path, and one shaded rest area. You will learn what KML is, what GeoJSON keeps, the steps to convert, and the checks that prove the tour survived the move.
If your end goal is a web page, this is the right road. If your end goal is Google Earth itself, stay with KML. Each format has a home ground, and the trick is to use each one where it is strong.
What Is KML, in Plain Words?
KML stands for Keyhole Markup Language. It is a text format built to show map data in Earth browsers like Google Earth. A KML file is XML text: tags in angle brackets that name each part. The main tag for one item is a Placemark. A Placemark holds a name, a note, a style, and one shape — a point, a line, or a polygon.
KML thinks about looks as much as data. It can set the color of a line, the icon of a pin, and the text that pops up when you click. Folders group Placemarks, so a tour can hold Day 1 and Day 2 in one file. A KMZ file is just a KML file packed in a ZIP, often with icons or images packed next to it.
That focus on looks is why people love KML for sharing a view. It is also why a straight move to a data format needs care. GeoJSON was built for data first. Styles live outside the file, in your map code. So the shapes and facts move well, while the paint stays behind — by design, not by fault.
What GeoJSON Keeps, and What It Drops
GeoJSON keeps the core: each Placemark becomes a feature, its shape becomes the geometry, and its name and note become facts on that feature. A point stays a point with the same longitude and latitude. A path stays a line with the same bends. A shaded area stays a polygon with the same edge.
GeoJSON drops the paint. Icon choices, line colors, and pop-up layout do not live in the GeoJSON file. Your web map code will set them instead — most often in a few lines that style all features of one kind at once. Most teams find this cleaner: one style rule for all pins beats a style stored 200 times in a data file.
Folders also flatten. GeoJSON has no folders. If your KML groups stops by day, add a fact before you convert — or check that the folder name lands in a field — so you can group the features again in your map code. Start from a CSV of points if your data is in a sheet instead, when the source was never drawn on a map at all: a sheet gives you clean fields from the start.
Words to Know
Four terms are enough for this road. The rest of the guide builds on them.
- Feature. one real thing on the map, such as one park, one road, or one shop. A file can hold many features.
- Geometry. the shape of a feature. A point is one spot. A line is a path. A polygon is a closed area with an edge.
- Attribute. a fact about a feature, stored as text or a number. A park has a name. A road has a speed limit. Those facts are attributes.
- Layer. one set of features of one kind, shown as one sheet on a map. A city file may hold a roads layer and a parks layer.
Why Make This Move?
KML is a fine format at home in Google Earth. The move to GeoJSON makes sense when the data needs a second life on the web:
- Your web map library — Leaflet, Mapbox, or OpenLayers — takes GeoJSON as its main data input.
- You want to join the shapes to other data, by name or ID, in code or in a database.
- You need the data in an app or an API, where JSON is the native tongue.
- You want one clean data file, with styles kept in your code where they can be changed in one place.
The move is a one-way edit in one sense: paint does not come back on its own. So keep the KML file as the record of how the tour looked in Google Earth. If you later need Earth again, you can send GeoJSON back to Google Earth as KML and set fresh styles there.
A Worked Example: A Walking Tour
Your KML holds a tour folder with five Placemarks: three stop points, one path line, and one rest-area polygon. Here is a short cut of the file, with one stop shown in full:
<Placemark>
<name>Old Mill</name>
<description>Stop 2. Tour meets at the gate.</description>
<Point><coordinates>-0.1357, 51.5201, 0</coordinates></Point>
</Placemark>
| KML item | Type in KML | Becomes in GeoJSON | Style kept? |
|---|---|---|---|
| Stop 1: Market Gate | Point Placemark | Point feature | No — set style in map code |
| Stop 2: Old Mill | Point Placemark | Point feature | No — set style in map code |
| Stop 3: Hill View | Point Placemark | Point feature | No — set style in map code |
| River Path | LineString Placemark | Line feature | No — line color set in code |
| Rest Area | Polygon Placemark | Polygon feature | No — fill set in code |
Five Placemarks go in. Five features must come out: three points, one line, one polygon. Names and notes ride along as facts. Note the order of the numbers in KML: longitude first, then latitude, then height. GeoJSON uses the same order for its pairs. A tool that swaps them puts London in the sea off Somalia, so the map check in this guide is not a formality — it is the test that catches the swap.
The height value is the third number. Most web maps work flat, in two dimensions, and drop the height. If your tour uses height in a real way — a cable car line, say — note that fact before you convert, and test one known point after the move.
Keep Your Source Safe
Work on a copy, not on your only file. Save the first file in a safe place and do not change it. If a test goes wrong, you can start again from the clean source. This sounds like a small point, but it saves more work than any other habit in this guide.
Give each test a clear name. A name like test-1 tells you the order of your tries. A name like final-final-2 tells you nothing at all. When you find the settings that work, write them down in a short note next to the files. The next file of the same kind will then take minutes, not an hour.
How to Convert KML to GeoJSON, Step by Step
The job is short. The checks are the job. Follow the steps in order, and do not merge the two count checks into one: KML items and GeoJSON features must match type by type.
Step 1: Open the file in Google Earth or a text app first
Take a look at what you have. Count the Placemarks, and note how many are points, lines, and polygons. Note the folder names too. If the file is a KMZ, that is fine — the tool reads the packed form. What you cannot do is convert a file you have not looked at. Two minutes here sets the counts you will check at the end.
Step 2: Upload the KML or KMZ file
Drop the file on the home page. The summary lists the features it found, by type, with names. Match that list to the count you made in Step 1. If a Placemark is missing from the list, it may hold a shape type the summary groups in a way you did not expect, like a track. Read the names, not just the total.
Step 3: Decide what to do about folders
If your file uses folders with meaning — days, teams, zones — check the field list for a folder field. If there is none, and the grouping matters, go back to the source and add the group as a fact on each Placemark before you convert. It is five minutes in Google Earth now, or an hour of hand work in the output later.
Step 4: Choose GeoJSON as the output
Pick GeoJSON from the format list. KML always uses longitude and latitude in WGS 84, and GeoJSON wants the same, so no coordinate change is needed. If the tool offers a target system, leave it at WGS 84 (EPSG 4326). This is the one road where the coordinate step is a free pass — take it, and spend your care on counts and names instead.
Step 5: Run the conversion and read the report
Click Convert. The report shows features in and out, by type. Three points, one line, and one polygon in must give the same out. It also lists the fields on each feature: name, description, and any extra facts the KML held in its data tags. If a field you rely on is not in the list, stop here, not after you build the map.
Step 6: Check the preview map
Look at the tour on the preview. Stops should sit on the right streets. The path should follow the river, not cut across blocks. The rest area should shade the park, not the road next to it. Click two or three features and read their facts. The name and note should be the ones from the KML, in the right feature, not shifted by one.
Step 7: Download and save the source with it
Download the GeoJSON and save it next to the KML. In your project note, write one line: styles were in the KML and must be set in map code. The next person to open the project will thank you. That one line stops a long hunt for a style file that never existed.
How to Check Your Result
Never trust a conversion you have not checked. The good news is that a sound check takes just a few minutes, and it is the same each time you work on a KML to GeoJSON job.
First, match the counts. The report shows how many features went in and how many came out. The two counts should be the same. If the output count is lower, a step dropped data, and you should find out why before you share the file.
Next, look at the map preview. Your data should sit in the right town, state, or sea. If it sits in the ocean, or on the wrong side of the world, the coordinate system is the prime suspect. Zoom in on one place you know well and check that roads, parks, or points fall where they should.
Then check the fields. Open the field list in the report and read the names. Make sure the key fields are still there, with the right names and the right kind of values. Pick one feature you know and match each value back to the source by hand.
- Check counts by type, not just in total. Three points, one line, and one polygon must stay three, one, and one.
- Open the GeoJSON in a text app and find one name you know. It should sit on the feature with the right shape next to it.
- If the source was a Shapefile-shaped problem in KML clothes — a partner drew it from GIS data — the steps to convert a Shapefile for a web map instead give the same end point from the true source.
Last, keep the source file. Save the result with a clear name that holds the date and the format, like parks-geojson-2026-11-07.zip. Keep the source and the result in one folder. If a question comes up next month, you can trace each feature back to where it came from.
Common Mistakes and How to Fix Them
A Placemark Is Missing in the Output
The item may be a special KML shape, like a ground overlay (an image laid on the map) or a network link (data loaded from the web). Those are views, not data, and they do not convert to features. If you need the thing under the overlay, get its source data file and convert that.
All the Points Sit in the Wrong Ocean
The longitude and latitude got swapped at some stage. True GeoJSON and KML both put longitude first. If your points sit in a neat grid in the wrong sea, the file you fed in may have been hand-made with the pair flipped. Fix the source pair order and run the job again.
Names Came Through but Notes Are Gone
Check how the notes were stored. A note in the standard description tag converts as a field. Text stored as styled HTML in a balloon may come through as raw markup, or be held in a different field. Read the field list in the report and find where the text landed before you retype anything by hand.
The Polygon Looks Inside Out
Some hand-drawn polygons have their ring drawn in a loose order, and strict readers may shade the outside of the ring instead of the inside. If your rest area shades the whole map with a hole in the middle, that is this fault. Redraw the ring in the source, or fix the ring order in the output with a GIS tool, then test the file again.
Styles Matter and Now They Are Gone
This one is by design, but it still bites teams that forgot to plan for it. The fix is in your map code: set one style per kind of feature, or per group field. Keep the KML as the style record, and write down the colors and icons it used, so your code can match them.
What the Plans Allow
You can start free. The Free plan gives you 5 conversions a month, with one file at a time and a size limit of 25 MB per file. That is enough to test a tour file or a partner's Google Earth export on real data and check the result with care.
Starter costs $9 a month. It gives you 200 conversions a month, files up to 500 MB, and batch jobs of up to 10 files at once. Pro costs $19 a month. It gives you 1,000 conversions a month, files up to 5 GB, batch jobs of up to 25 files, and API access for work you run on a schedule. You can check the pricing page for batch sizes before you pick.
All plans work the same way at the core. You get a map preview, feature counts in and out, and a clear report if a file has a fault. Your files are kept for 72 hours so you can download them again, and then they are deleted.
Frequently Asked Questions
Does GeoJSON support the icons and colors in my KML?
Not in the file itself. GeoJSON holds shapes and facts. Your map library sets icons and colors in code. This is a strength for web work: change one rule and every pin changes at once. But it does mean the move drops the paint stored in the KML.
Can I convert a KMZ file the same way?
Yes. A KMZ is a KML packed in a ZIP. Upload it as it is. One note: images or icons packed in the KMZ do not move to GeoJSON. If a Placemark points to a packed icon, the feature keeps its shape and facts, but not the image.
What happens to tracks from a GPS device?
A GPS track in KML is a special Placemark type. It should come out as a line feature with the path points in order. Check the line on the preview: it should follow the roads or trails you walked, with no jumps. If your source is a raw GPX file, the tool also reads GPX as an input.
My KML has hundreds of Placemarks. Is that a problem?
No. Count checks matter more as files grow, not less. Use the report counts by type, and spot-check a few names from the start, the middle, and the end of the list. Big hand-made files are where one missing item hides best.
Can I edit the GeoJSON and send it back to Google Earth?
Yes. Edit the facts or shapes, then convert back to KML for Earth. Styles will need to be set again in Earth or in the KML. Keep both files in the project, each named for the tool it serves.
Final Checklist
Run through this short list before you share your file:
- Feature counts match the KML counts, by type.
- Names and notes sit on the right features.
- The preview puts stops and paths on the right streets.
- Folder groups you need are stored as a field.
- The KML source is saved next to the GeoJSON, with a note that styles live in code.
If each point passes, your file is ready to use.
References
- https://www.ogc.org/standards/kml — The Open Geospatial Consortium KML standard page. KML 2.2 is an OGC standard.
- https://www.rfc-editor.org/rfc/rfc7946 — RFC 7946, the GeoJSON specification. It defines features, geometry types, and the coordinate order.
- https://developers.google.com/kml/documentation/kml_tut — The Google KML tutorial. It shows Placemarks, paths, and polygons as Earth users make them.