KML to CSV Converter
KML (Keyhole Markup Language) is the XML format Google Earth, Google Maps exports, GIS desk tools, and many field apps use to store placemarks, paths, and overlays. Spreadsheets and most data pipelines expect flat tables. This free KML to CSV converter reads placemark data in your browser, extracts names and coordinates, and writes clean CSV rows you can open in Excel, Google Sheets, QGIS attribute joins, or another converter on this site.
Paste a .kml document or upload the file. The tool walks Placemark elements—including those nested inside Folders—reads Point coordinates, and splits KML’s longitude,latitude,altitude order into separate latitude, longitude, and altitude columns. Your KML is not uploaded to a server as part of the conversion. KMZ packages must be unzipped first so you paste or upload the inner .kml.
Below you will find how coordinate order works, how MultiGeometry becomes multiple rows, what polygon and path data this tool does and does not flatten, Excel pitfalls after download, and a full troubleshooting and FAQ section for real Google Earth and field-mapping workflows. Use the preview as your source of truth before you download or share the file. The reverse path—building KML from a spreadsheet—is covered by the CSV to KML converter.
Key features
- Extracts Placemark names and Point coordinates into spreadsheet-ready columns.
- Splits KML longitude,latitude,altitude tuples into separate latitude, longitude, and altitude fields.
- Walks nested Folder structures so deep placemark trees still become rows.
- Splits MultiGeometry Points into one CSV row per point for countable pin lists.
- Accepts pasted KML text or an uploaded .kml file — no desktop GIS license required.
- Runs entirely in the browser so your placemark file is not sent to a server for conversion.
- Produces standard CSV ready for Excel, Google Sheets, or the reverse CSV to KML tool.
About the KML to CSV format
KML is an XML vocabulary: Document and Folder containers hold Placemark elements; each placemark typically has a name and a geometry such as Point, LineString, Polygon, or MultiGeometry. CSV is a plain-text grid with a header row and one row per record. Conversion for this tool means treating each useful placemark point as one row and projecting name plus lat/lon/alt into columns.
In KML, <coordinates> lists values as longitude,latitude[,altitude]—longitude first, which is the opposite of how many people say “lat/lon” in conversation. The converter parses that tuple and writes separate latitude and longitude columns so spreadsheet users do not have to mentally swap axes. Optional altitude becomes its own column when present.
Nested Folders are walked so placemarks deep in a hierarchy still appear as rows. MultiGeometry that contains multiple Points is split into multiple CSV rows (one per point). This is a placemark-oriented export, not a full GIS polygon or topology engine: closed rings, styles, NetworkLinks, and ground overlays are outside the flat table model.
How it works
The parser loads your KML into a DOM tree in the browser and collects Placemark elements wherever they appear under Document or nested Folder nodes. For each placemark it reads the <name> (when present) and looks for Point geometry—or Points inside a MultiGeometry.
Each Point’s <coordinates> string is split on commas. Per the KML specification the order is longitude, then latitude, then optional altitude. Those values are mapped into dedicated CSV columns so consumers never have to remember KML’s lon-first convention when filtering or plotting.
When MultiGeometry contains several Points, each Point becomes its own row, typically repeating the placemark name. The result is escaped for spreadsheet use (commas, quotes, newlines) and ready to copy or download. Polygon rings and path vertices are not treated as a full GIS dump.
Common use cases
- Exporting Google Earth placemarks from a site survey into a spreadsheet for the project manager.
- Turning a saved My Maps or Earth .kml of store locations into CSV for a CRM or store-locator import.
- Extracting trailhead and campsite points from a hiking KML for a logistics checklist in Sheets.
- Converting field-collector KML dumps (inspection pins, photo waypoints) into rows for QA review.
- Sharing a colleague’s Earth placemark set with teammates who only work in Excel and never open .kml.
- Preparing lat/lon columns from a KML layer before joining to other CSV datasets or charting in BI tools.
How to use this tool
- If your file is .kmz, unzip it and open the .kml inside; otherwise paste or upload the .kml directly.
- Confirm the preview lists the placemarks you expect, including those nested in Folders.
- Spot-check latitude and longitude on a known location — remember the source KML was lon,lat.
- Check that MultiGeometry pins produced the right number of rows, then copy or download the CSV.
- Open a sample in Excel or Sheets and verify names, coordinate precision, and altitude before sharing.
Example
Input KML
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<Placemark>
<name>Trailhead</name>
<Point>
<coordinates>-122.4194,37.7749,10</coordinates>
</Point>
</Placemark>
</Document>
</kml>Output CSV
name,latitude,longitude,altitude
Trailhead,37.7749,-122.4194,10Tips for best results
- If you have a .kmz, unzip it first and use the .kml inside — KMZ is a zip wrapper, not plain KML text.
- Remember KML stores longitude first; after conversion, confirm latitude and longitude columns are not swapped in your head when spot-checking.
- Nested Folders are fine — you do not need to flatten the hierarchy before pasting.
- MultiGeometry with several Points becomes several rows; check row count against how many pins you expect.
- Rename or add columns (id, category, notes) in the Online CSV Editor after conversion if your placemarks only had names.
- Keep the original .kml until you verify a few known landmarks against a map using the CSV lat/lon.
- For the reverse workflow—CSV columns back into Google Earth—use the CSV to KML converter on this site.
Common errors and how to fix them
- Uploading or pasting a .kmz does nothing useful or fails to parse.
- KMZ is a compressed zip archive that contains one or more KML files (and often icons). Unzip the KMZ with your OS archive tool, locate the .kml (often doc.kml), then paste or upload that KML text instead.
- Points appear in the wrong place on the map after I plot the CSV.
- You likely swapped latitude and longitude when joining or charting. KML stores longitude first inside <coordinates>; the converter already splits into labeled columns—use the latitude column as Y and longitude as X, and do not reverse them again.
- I expected dozens of polygon vertices but only see a few rows (or none).
- This converter is oriented around Placemark Points, not full polygon or LineString vertex dumps. For ring-level GIS work use a dedicated GIS export (GeoJSON, shapefile) or a tool that expands LinearRing coordinates; do not expect a complete polygonal GIS table here.
- Folder structure disappeared and everything is one flat list.
- CSV is a flat table. Nested Folders are traversed so you do not lose placemarks, but folder names are not automatically turned into a hierarchy column unless present as placemark fields. Add a category column in the editor if you need group labels.
- MultiGeometry produced more rows than placemarks in Google Earth.
- That is expected when one placemark contains multiple Points: each Point becomes a row so every pin is countable. Filter or merge rows in the Online CSV Editor if you need one row per placemark name instead.
- The tool reports a parse error on a file that opens fine in Google Earth.
- Earth can be forgiving of minor XML issues or may be reading a KMZ while you pasted binary garbage. Validate that you pasted well-formed XML KML (not KMZ bytes), with a single root and proper namespaces, and try exporting a clean .kml from Earth again.
Best practices
- Always unzip KMZ before conversion; treat KMZ as a package and KML as the document this tool reads.
- Verify at least one well-known placemark’s lat/lon on a map after conversion before trusting the whole sheet.
- Name placemarks in Earth before export so the CSV name column is useful out of the box.
- When MultiGeometry is involved, reconcile row counts with pin counts so you know whether one-to-many expansion occurred.
- Keep the source .kml alongside the CSV until stakeholders confirm the extract; KML still holds styles and camera views CSV cannot.
- Document CRS expectations: KML coordinates are geographic (WGS 84 lon/lat). Do not treat them as Web Mercator meters.
- Use CSV to KML when you need to round-trip cleaned spreadsheet rows back into Google Earth.
What KML to CSV conversion actually does
Google Earth and similar viewers are excellent for browsing pins on a globe. Spreadsheets, CRMs, and many ETL tools want rows and columns. This conversion reads KML Placemark structure and writes each useful point as a CSV record with a name and coordinate fields.
You keep labels and WGS 84 geographic coordinates, not balloon HTML styling, camera tilt, or icon hrefs. That is usually what operations and analysis teams need when the next step is a filter, a join, or a bulk import.
It is not a full GIS translation: topology, polygon interiors, network links, and time-animated tracks are outside a simple flat file. Paste or upload KML that already contains the placemarks you care about.
When to convert KML placemarks to CSV
Convert when someone shared an Earth .kml of sites, assets, or waypoints and your workflow lives in Excel or Sheets; when a CRM or logistics tool wants latitude and longitude columns; or when you need a quick inventory of pins without installing desktop GIS.
Skip conversion if you need editable polygons, style libraries, or Tours—keep the KML (or use GeoJSON/shapefile for serious GIS). Skip if the deliverable must remain a KMZ package with embedded icons for Earth-only recipients.
A practical pattern: export or receive KML, convert placemarks to CSV, clean names and categories, then either analyze in Sheets or push back out with CSV to KML after spreadsheet edits.
- Good fit: store locators, survey pins, trailheads, inspection waypoints, simple asset maps.
- Poor fit: complex cadastral polygons, 3D models, NetworkLink live feeds, ground overlay imagery packages.
- Better in GIS software: large MultiGeometry polygons, topology checks, reprojection to local CRS.
KMZ versus KML: unzip first
KML is XML text. KMZ is essentially a zip file: typically a doc.kml plus optional images and overlays. This converter expects KML markup it can parse as XML, not a compressed binary archive pasted into a text box.
On macOS or Windows, rename or open the .kmz with your archive utility, extract the contents, and locate the .kml file. Upload or paste that document. If multiple KML files exist inside, convert the one that holds your placemarks (often doc.kml).
After conversion you have CSV only—icons and overlay images from the KMZ are not embedded in the spreadsheet. Keep the KMZ if visual packaging still matters for Earth users.
Coordinate order: longitude, latitude, altitude
The KML specification writes <coordinates> as lon,lat[,alt]. A San Francisco–area point might look like -122.4194,37.7749,10—west longitude first, then latitude, then meters altitude. People who habitually say “lat/lon” often mis-read that string and plot points near the wrong continent.
This converter splits the tuple into clearly named latitude, longitude, and altitude columns. Downstream, treat latitude as the north–south value and longitude as the east–west value. Do not swap columns again when importing into tools that also say “lat, lon” in their UI.
Altitude may be missing; KML allows two-number coordinates. Blank altitude cells are normal for 2D placemarks. Absolute versus clamp-to-ground altitude modes from KML are not fully modeled in CSV—you get the numeric altitude when present, not the full altitudeMode semantics.
Folders, Documents, and nested placemarks
Real-world Earth files rarely dump every pin at the Document root. Users organize pins into Folders (regions, phases, vendors). The converter walks nested Folders so you do not have to manually explode the tree in a text editor before pasting.
CSV cannot represent a folder tree natively. You get a flat list of placemark rows. If folder names matter for filtering, add a category column after conversion, or encode group info into placemark names before export from Earth.
Multiple Documents inside one KML are uncommon but possible in concatenated or hand-edited files. Prefer a single well-formed Document exported from Earth when you control the file.
MultiGeometry: one placemark, many rows
A Placemark can wrap a MultiGeometry that contains several Points (or mixed geometry types). Visually in Earth you may still see one placemark entry with multiple pins. For spreadsheet counting and joins, each Point should usually be its own row.
This converter splits MultiGeometry Points into separate CSV rows, typically carrying the same placemark name on each. That makes row counts match pin counts for QA (“we should see 12 inspection points”).
If you instead need one row per placemark with concatenated coordinates, merge after conversion in the Online CSV Editor or a small script—the default one-row-per-point shape is intentional for tabular workflows.
What this tool is not: polygons and full GIS
LineStrings and Polygons store long coordinate lists that define paths and rings. Turning every vertex into CSV is a different product: attribute tables plus geometry columns, often as WKT or GeoJSON, with CRS metadata.
Here the focus is placemark Points suitable for store lists, waypoints, and pin inventories. Do not expect a faithful vertex-by-vertex dump of every LinearRing, nor topology validation, nor style URL resolution.
When you need true GIS interchange, export GeoJSON or shapefile from QGIS, ArcGIS, or Earth Pro workflows designed for that purpose, then use CSV only for attribute side-tables if needed.
Names, descriptions, and ExtendedData
The <name> element becomes the primary label column—worth filling carefully in Earth before export. Empty names yield blank cells that force later guessing (“which pin is this?”).
Rich <description> HTML and balloon content often do not map cleanly to a single CSV cell; expect name and coordinates to be the reliable core. ExtendedData/SchemaData custom fields may appear depending on how structured the KML is—spot-check the preview if you rely on custom attributes.
If critical business fields live only in description HTML, extract them manually or with a dedicated scrape after you have the coordinate skeleton in CSV.
Excel, Sheets, and after-download cleanup
CSV opens widely, but Excel may auto-format numbers and reduce displayed precision on coordinates. Widen columns and set more decimal places when verifying pins; small rounding can matter at street level.
If everything lands in one column, your locale may expect semicolons—use Text Import with comma selected. Keep leading signs on longitudes (negative in the western hemisphere).
Add id, category, or notes columns in the Online CSV Editor, drop accidental empty rows, and save a dated filename when the extract informs a field visit or board decision.
Typical workflows
Site survey: field team drops pins in Earth, exports KML, convert to CSV for the PM’s tracking sheet, then CSV to KML after status columns are updated.
Retail or facilities: My Maps or Earth layers of locations become CRM imports with lat/lon columns.
Outdoor and events: trailheads, stages, and aid stations move from a shared KML into volunteer spreadsheets.
QA of vendor data: vendor sends KMZ of assets; unzip, convert, compare row counts and sample coordinates against a contract list.
Browser limits, privacy, and sensitive locations
Parsing is local. Pasted or uploaded KML is not sent to Convert CSV servers for the transform. Site analytics and advertising follow the privacy policy separately.
Very large KML files with tens of thousands of placemarks can slow the tab. Split by Folder in Earth and convert in batches when the browser struggles.
Placemarks can encode private homes, critical infrastructure, or unreleased project sites. Even with client-side conversion, control who receives the CSV and avoid leaving sensitive .kml on shared machines.
Round-trip with CSV to KML
Teams often edit attributes in a spreadsheet then need pins back in Earth. After cleaning names and coordinates in CSV, use the CSV to KML converter to rebuild placemarks.
Round-trips preserve the tabular core (name, lat, lon, alt) better than styles, folders, and camera views. Re-apply folder organization and icons in Earth after import when presentation matters.
Always re-check axis order on the way back: your CSV should keep explicit latitude and longitude columns so the reverse tool does not have to guess.
Quality checklist before you share the CSV
Confirm placemark count roughly matches Earth (accounting for MultiGeometry expansion). Confirm latitude/longitude on one known landmark. Confirm altitude blanks are acceptable for 2D pins.
Open in the recipient’s spreadsheet app. Note whether the source was KML or unzipped KMZ, and record export date when the layer changes often.
- KMZ unzipped to KML before convert.
- Lat/lon not swapped vs a known pin.
- Names filled or intentionally blank.
- MultiGeometry row counts understood.
- Not expecting full polygon GIS output.
Related tools and next steps
Need pins again in Google Earth after spreadsheet edits? Use CSV to KML. Need to inspect or reshape columns first? Use the Online CSV Editor.
Continuing into JSON APIs or SQL staging tables? Use CSV to JSON or CSV to SQL after the placemark extract looks right. Site guides cover Excel import quirks when the open step misbehaves.
Frequently asked questions
Can I convert a KMZ file directly?
Not as a binary upload of the archive contents into the KML parser. Unzip the KMZ, then paste or upload the .kml file inside (often named doc.kml). KMZ is a zip package; this tool reads KML XML.
Why does KML list longitude before latitude?
That order is part of the KML/OGC coordinate convention for <coordinates>. The converter splits the values into labeled latitude and longitude columns so spreadsheet users can follow the column names instead of memorizing lon-first strings.
Are nested Folders supported?
Yes. Placemarks inside nested Folders are still collected into CSV rows. Folder hierarchy itself is flattened because CSV is a table, not a tree.
What happens with MultiGeometry?
Points inside a MultiGeometry are emitted as separate rows, usually sharing the placemark name, so each pin is countable in the spreadsheet.
Does this export full polygons and paths?
No. It is aimed at placemark Points for pin lists and inventories, not a complete GIS vertex dump of LineStrings or Polygon rings. Use dedicated GIS export formats when you need full geometry.
Is my KML uploaded to a server?
No. Conversion runs in your browser. See the Privacy Policy for site analytics and advertising.
How do I get CSV back into Google Earth?
Use the CSV to KML converter on this site after your latitude, longitude, and name columns are clean, then open the resulting KML in Earth.
Why are some name cells empty?
Those placemarks had no <name> in the KML. Add names in Earth before export, or fill the column in the Online CSV Editor after conversion.
What coordinate reference system does the CSV use?
KML geographic coordinates are WGS 84 longitude/latitude (and optional altitude). The CSV inherits those geographic values—do not treat them as projected meters.
Can I convert multiple KML files at once?
Convert one document at a time for clear previews, then append CSVs in a spreadsheet when columns match. Mixing unrelated layers in one paste makes QA harder.
Why do I have more CSV rows than placemarks in the Earth sidebar?
MultiGeometry (or multiple Points under one placemark) expands to one row per point. That is expected for pin-level tables; merge rows if you need one row per placemark entry.
Will styles, icons, and balloons appear in the CSV?
No. CSV keeps tabular fields such as name and coordinates. Keep the original KML or KMZ when visual styling and balloon HTML still matter.
For more background on data formats and conversion workflows, read our format guides or browse the converter blog for step-by-step walkthroughs linked to each tool.