lon,lat, not lat,lon: why your KML points are in the ocean

Short answer: <coordinates> in a KML is lon,lat — longitude first, latitude second, altitude third if present — in WGS 84, always, with nowhere in the format to say otherwise. Write a Brazilian pair the other way round and the point does not land somewhere approximate; it leaves the continent. "My points are in the ocean" is the phrase people search for; this post is the ten-second diagnosis, and why no tool will do it for you.

Tested on 1 October 2026 in the kmz-viewer and the geojson-viewer, in all three interface languages, with the exported GeoJSON read off disk as the oracle for where each point went rather than a screenshot of the map. Every quoted string below is the tool's own.

What the viewer shows when the pair is backwards

Nothing. That is the finding, and it is the whole problem.

Drop São Paulo written correctly — -46.63880000,-23.54890000 — into either viewer and the layers panel reads 1 point. Swap the two numbers to -23.54890000,-46.63880000 and it still reads 1 point: no error banner, no warning colour, nothing. The file loads, the layer row mounts, the count is right — identically in both viewers and all three languages.

The export is where it becomes visible. Export then Export GeoJSON writes [-46.6388,-23.548900000000017,0] for the correct file and [-23.5489,-46.63880000000002,0] for the swapped one. Longitude 23.5489 W with latitude 46.6388 S is outside Brazil on every bound of the national extent, and further south than any point in the country. Two details before you compare pairs by eye: a third ordinate 0 is appended whether or not your <coordinates> carried one, and the latitude comes back with about 1e-14 of floating-point noise on it while the longitude comes back exact, which is why the longitude is the number to trust. And a half-wrong file gets no extra help: a two-placemark KML with the first pair right and the second swapped reads 2 points, with nothing to say that one of the two is off-world.

The geojson-viewer takes a .kml too, so you need not switch tabs: its dropzone says Drag a GeoJSON, KML or KMZ file here, and the same bytes parse the same way whether you pick the file or drag it onto the page, with byte-for-byte identical exports. What the file is named matters far more than how it arrives. Rename those same KML bytes to .geojson and the viewer refuses them with Error processing file. Make sure it is a valid GeoJSON file., because the parser dispatches on the extension and then hands KML to a JSON reader. Rename them to .txt and you get Unsupported file type. Use GeoJSON (.geojson or .json), KML or KMZ. — including on the drag path, where the picker's filter cannot have been involved.

The ten-second diagnosis

Look at the magnitudes and ignore the signs. The measured extent of a national dataset puts Brazilian longitudes between 28.84764 and 73.99045 in absolute value, and Brazilian latitudes nowhere above 33.75. A Brazilian latitude is therefore small and negative, a Brazilian longitude large and negative, so -46.6388 in the first slot beside -23.5489 in the second is a pair the right way round. Reversed, the file opens with -23.54890000 — far too small to be any Brazilian longitude, sitting where the longitude belongs. That is the tell, and it needs no tool.

Why nothing can catch it in general

Because -46.63 is a perfectly valid latitude. It is inside WGS 84's -90 … 90, the forward projection accepts it, the point draws, the counter counts it, the export writes it back out. There is no invalid value anywhere in the file for a validator to find.

And the magnitude rule is not a law, it is a coincidence about the shape of Brazil — one that fails in two measurable places. The two bands above overlap at the bottom of the longitude range: for any magnitude between 28.84764 and 33.75 the number is at once a plausible Brazilian latitude and a plausible Brazilian longitude, and that band is southern Rio Grande do Sul against the far-eastern Atlantic coast — a populated corner of the country, not a pathological one. Near the origin the rule has nothing to work with. Accra is -0.18700000,5.60370000; swapped to 5.60370000,-0.18700000 it draws at 5.6037 E, 0.187 S, and both numbers are valid in either slot. The viewer reads 1 point and shows no banner, exactly as before. Points that land at or near zero are a family of their own — a point at zero, or somewhere in the Gulf of Guinea covers them, and that is where the Gulf of Guinea belongs, not in a Brazilian swap, which cannot reach it.

Nor does the tool meet you halfway on the impossible cases. A latitude of -123.40000000 — outside -90 … 90, so not a latitude at all — loads with no banner, counts as 1 point, and exports as [-46.6388,null,0]: a JSON null where a number is required. Nothing in the viewer stands between a bad coordinate and a drawn map, which is why the exported pair is the diagnosis and the drawn map is not.

Fixing it

For a handful of placemarks a text editor is the whole repair: open the KML, swap the two numbers inside each <coordinates>, save, drop it again and read the first pair out of a fresh export. Nothing is reprojected, because there is nothing to reproject: a KML has no place to declare a coordinate system, so a file in the wrong place has the wrong numbers in it, not the wrong CRS. That rule, and the command-line transcripts behind it, sit under the heading "Coordinates: always lon,lat, always WGS 84" in the KML and KMZ guide, which also covers the two mistakes that look identical from the map: projected metres written as degrees, and degrees-minutes-seconds pasted in raw. If the numbers came out of a UTM dataset, the zone and hemisphere are their own trap — see UTM to latitude and longitude.

Test files you can use

Nothing is hosted. Paste a placemark between <?xml version="1.0" encoding="UTF-8"?>, <kml xmlns="http://www.opengis.net/kml/2.2"><Document> and </Document></kml> and save it as a UTF-8 .kml. Every coordinate here is decimal on purpose.

• Correct, the control: <Placemark><name>Sao Paulo</name><Point><coordinates>-46.63880000,-23.54890000</coordinates></Point></Placemark>
• Swapped, the subject — the same two numbers reversed: <Placemark><name>Sao Paulo swapped</name><Point><coordinates>-23.54890000,-46.63880000</coordinates></Point></Placemark>
• Swapped near the origin, where the tell stops working: <Placemark><name>Accra swapped</name><Point><coordinates>5.60370000,-0.18700000</coordinates></Point></Placemark>
• A latitude outside the valid range: <Placemark><name>out of range</name><Point><coordinates>-46.63880000,-123.40000000</coordinates></Point></Placemark>

Put the first two placemarks in one file to get the half-wrong case that reads 2 points.

For teams

A swapped pair is almost always a handover: one person wrote the pair in one order, someone else read it in the other, and the file carries no hint of which was meant. Geodocs keeps field data on one shared map, where the coordinate order is settled once by the form instead of once per file.