KML coordinate order (lng, lat, alt) confusion
Your KML opens in the wrong place in Google Earth, or a KML you built from a spreadsheet puts every placemark on the wrong continent. The numbers look right but the order seems off.
Why it happens
Inside a KML <coordinates> element, each tuple is written longitude,latitude,altitude — longitude first, comma-separated, no spaces between the values of a tuple. This matches GeoJSON's longitude-first order but is the opposite of the spoken 'latitude, longitude'. When a KML is generated from a CSV or API that lists latitude first, and the columns aren't flipped, every placemark ends up reversed. The altitude value is optional, which adds confusion when a two-value tuple is mistaken for lat,lng.
How to fix it
- Open the lat/lng swap checker and paste a few of your coordinate tuples to see where they land.
- Confirm the KML order: each tuple must be longitude,latitude(,altitude). If your first value exceeds ±90 it cannot be a longitude, so the tuple is reversed.
- If the order is wrong, swap longitude and latitude in every tuple so longitude comes first.
- Re-open in Google Earth (or convert to GeoJSON and preview) to confirm placemarks now sit in the correct location.
Frequently asked questions
What order are coordinates in a KML file?
Longitude, then latitude, then optional altitude — written as lon,lat,alt with commas and no spaces inside a single tuple. This is longitude-first, the same as GeoJSON and the opposite of the usual spoken 'lat, lng'.
Why does my KML show placemarks in the wrong place?
The most common reason is that the longitude and latitude were swapped when the KML was generated — typically from a CSV or API that listed latitude first. Flipping the two values inside each <coordinates> tuple fixes it.
Is the altitude value required in KML coordinates?
No, altitude is optional. A tuple can be lon,lat or lon,lat,alt. Trouble arises when a lon,lat pair is misread as lat,lng, or when altitude is omitted and a tool expects three values.
Does KML use the same coordinate order as GeoJSON?
Yes — both put longitude before latitude. So a swap that breaks a KML will usually break a GeoJSON built from the same source, and the same fix (flip to longitude-first) applies to both.