CSV to KML Converter Online Free

CSV to KML Converter

Spreadsheets are where store lists, survey pins, and delivery stops usually live. Google Earth and many mapping viewers expect KML—an XML format of Placemarks with Point coordinates. This free CSV to KML converter reads latitude and longitude columns from your CSV, builds one Point Placemark per valid row, and wraps them in a standard KML Document you can open directly in Google Earth.

Paste CSV or upload a .csv file with recognizable coordinate headers (latitude/lat and longitude/lng/lon/long). A name, title, or label column becomes each placemark’s display name; rows without a usable numeric coordinate pair are skipped. Conversion runs entirely in your browser—your spreadsheet is not uploaded to a server as part of the transform. You get plain .kml text; KMZ zip packaging is not required to open the result in Earth.

Below you will find how lat/lon columns map into KML’s longitude-first <coordinates> order, how name and description fields relate to placemark labels, what this tool does and does not generate (Points only—not polygons or paths), Excel and geocoding pitfalls, the reverse path with KML to CSV, and a full troubleshooting and FAQ section for real Google Earth workflows. Use the preview as your source of truth before you download or share the file.

Key features

Builds a valid KML 2.2 Document with one Point Placemark per CSV row that has usable coordinates.
Detects latitude/lat and longitude/lng/lon/long headers case-insensitively for common spreadsheet naming.
Uses name, title, or label columns for placemark <name>, with Placemark N fallback when none is present.
Writes <coordinates> in KML’s required longitude,latitude,altitude order so you do not reorder columns by hand.
Skips rows without finite numeric lat/lon instead of emitting broken zero-zero pins.
Runs entirely in the browser so location lists are not sent to a server for conversion.
Produces plain .kml ready for Google Earth—no KMZ packaging step required for Point placemarks.

About the CSV with latitude and longitude columns to KML format

CSV is a flat table: a header row plus one record per line. KML is XML: a Document holds Placemark elements; each placemark typically has a <name> and a geometry such as Point. Conversion here means treating each row with valid latitude and longitude as one Point Placemark inside a single Document.

Your spreadsheet should keep latitude and longitude in separate columns. Common header names are detected case-insensitively: lat or latitude for the north–south value, and lon, lng, long, or longitude for the east–west value. The converter writes KML <coordinates> as longitude,latitude,altitude—longitude first, per the KML specification—even when your CSV columns are labeled the other way around conversationally.

A column named name, title, or label (case-insensitive) becomes the placemark <name>. If none of those headers exist, placemarks are labeled Placemark 1, Placemark 2, and so on. Other CSV columns are not turned into LineString or Polygon geometry; this path is point pins for Earth, not a full GIS geometry writer. Altitude in the output Point is set to 0 for a simple 2D pin list.

How it works

The converter parses your CSV into headers and rows, then locates coordinate columns by matching headers against lat/latitude and lon/lng/long/longitude (case-insensitive). If either coordinate column is missing, conversion cannot proceed—rename headers first.

For each data row it reads the latitude and longitude cells as numbers. When both values are finite, it creates a Placemark: the display name comes from a name, title, or label column when present, otherwise Placemark {row number}. The Point’s <coordinates> string is written as longitude,latitude,0—KML order, with a default altitude of zero for 2D pins.

Invalid coordinate rows are omitted from the placemark list. Surviving placemarks are wrapped in a Document inside a root <kml> element with the standard OGC KML 2.2 namespace. You copy or download that XML and open it in Google Earth or another KML-capable viewer.

Common use cases

Visualizing store or depot locations from a spreadsheet as pins in Google Earth.
Plotting field-survey waypoints from a CSV of lat/lon onto a shared Earth layer for a project review.
Creating delivery or site-visit placemarks from a geocoded address list exported as CSV.
Turning a heritage-site or event-venue spreadsheet into a KML colleagues can open without GIS software.
Rebuilding Earth pins after cleaning names and coordinates in Sheets—the reverse of a KML to CSV extract.
Sharing a simple pin layer with stakeholders who only know how to File → Open a .kml in Google Earth.

How to use this tool

Prepare a CSV with latitude and longitude columns (and ideally a name/title/label column); use decimal degrees.
Paste the CSV or upload the .csv file into the converter.
Confirm the preview placemark count matches the rows you expect to plot (account for skipped bad coordinates).
Spot-check names and a known lat/lon pair against a map before trusting the full batch.
Download the .kml and open it in Google Earth—no KMZ zip step required for these Point placemarks.

Example

Input CSV

name,latitude,longitude
Trailhead,37.7749,-122.4194
Warehouse A,40.7484,-73.9857

Output 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,0</coordinates></Point>
    </Placemark>
    <Placemark>
      <name>Warehouse A</name>
      <Point><coordinates>-73.9857,40.7484,0</coordinates></Point>
    </Placemark>
  </Document>
</kml>

Tips for best results

Name coordinate columns latitude and longitude (or lat / lng) so detection is automatic.
Include a name (or title/label) column with human-readable labels for the Earth sidebar.
Use decimal degrees, not degrees-minutes-seconds text, in the coordinate cells.
Spot-check one known city pin after open—swapped lat/lon is the most common silent failure.
Latitude must fall roughly in −90…90 and longitude in −180…180; out-of-range values often mean swapped columns.
Clean blanks and non-numeric coordinate cells in the Online CSV Editor before converting so fewer rows are skipped.
Plain .kml is enough for Google Earth—you do not need to zip into KMZ for basic placemarks.
Use KML to CSV when you need to pull existing Earth pins back into a spreadsheet.

Common errors and how to fix them

The tool says the CSV must include latitude/longitude columns.: Rename headers so coordinates are detectable: latitude or lat, and longitude, lon, lng, or long (case-insensitive). Headers like y_coord / x_coord or Location Lat are not matched—use the Online CSV Editor to rename first.
Placemarks appear in the wrong place on the globe.: Latitude and longitude are almost certainly swapped in the source CSV. Latitude ranges about −90 to 90; longitude about −180 to 180. If your “latitude” column holds values like −122, those are longitudes—swap the columns and convert again.
Some CSV rows never show up as pins in Google Earth.: Rows without finite numeric latitude and longitude are skipped. Check for blanks, text notes in coordinate cells, or DMS strings. Fix those cells, then reconvert; compare Earth pin count to valid numeric rows, not raw CSV length.
Every pin is named Placemark 1, Placemark 2, …: No name, title, or label column was found. Add or rename a column to name (or title/label) with the sidebar text you want, then run the conversion again.
Google Earth will not open the file or shows an empty map.: Confirm the download is .kml text (not an empty document from zero valid rows). Open the file in a text editor and verify you see <kml>, <Document>, and at least one <Placemark>. Re-export after fixing coordinate columns if the Document is empty.
I expected polygons or a driving route path, not separate pins.: This converter creates one Point placemark per row. For LineString paths or Polygon footprints, use GIS software or hand-authored KML geometry—tabular lat/lon rows alone are mapped to points here.

Best practices

Standardize headers to latitude, longitude, and name before converting so detection and labels stay predictable.
Verify at least one well-known landmark’s position in Earth after every batch conversion.
Keep coordinates in WGS 84 decimal degrees; do not paste projected meters into lat/lon columns.
Treat skipped-row counts as a QA signal—reconcile against source data before sharing the KML.
Prefer plain KML for simple pin sets; only build KMZ when you need bundled icons or overlays Earth consumers require.
Round-trip with KML to CSV when stakeholders edit pins in Earth and you need the table back in Sheets.
Store the source CSV alongside the .kml until reviewers confirm names and positions—spreadsheets remain easier to edit.

What CSV to KML conversion actually does

Operations teams maintain locations as rows: a label, a latitude, a longitude, maybe a status column. Google Earth does not open CSV natively as a polished pin layer the way it opens KML. This conversion bridges that gap by emitting Placemark Points your colleagues can File → Open without a GIS license.

You keep the tabular core—who/what and where—as named pins on the globe. You do not get a full style library, folder tree, tour, or ground overlay package from a flat sheet in one click. That trade-off is intentional: fast pins from spreadsheets, not a replacement for desktop GIS cartography.

Think of the output as a clean Document of Point placemarks. Enrich icons, balloons, and folders in Earth afterward when presentation matters more than the initial drop of coordinates.

When to convert CSV coordinates to KML

Convert when a store list, survey sheet, or geocoded CRM export needs to appear as pins in Google Earth; when field leads only accept .kml; or when you cleaned coordinates in Sheets and must push pins back to Earth after a KML to CSV round-trip.

Skip this path if you need closed polygons, multi-vertex routes, NetworkLinks, or time-animated tracks—those geometries need GIS tooling or hand-built KML. Skip if recipients require a KMZ with embedded custom icons and imagery; plain Point KML may be enough visually, but packaging assets is a separate step.

A practical pattern: maintain the master list in CSV, convert to KML for Earth reviews, collect feedback, edit the sheet, and convert again. Use KML to CSV when someone else edited pins only in Earth and you need the table back.

Good fit: store locators, waypoints, inspection pins, event venues, simple asset maps.
Poor fit: cadastral polygons, trail centerlines as paths, 3D models, live NetworkLink feeds.
Better in GIS: reprojection, topology, large MultiGeometry authoring, styled KMZ packages.

Column detection: latitude, longitude, and names

Headers drive success more than column order. The converter looks for lat or latitude, and for lon, lng, long, or longitude—case does not matter. Once found, values are read by index; you do not need longitude to sit left of latitude in the sheet.

For labels, name, title, or label map to the placemark <name> shown in Earth’s places panel. Pick one clear naming column; if several match the pattern, the first matching header wins. Without any of those headers, sequential Placemark N names keep the file valid but harder to navigate.

Other columns (category, address, notes) are useful in the spreadsheet workflow, but this converter’s KML focus is name plus Point coordinates. Put the string you need in the sidebar into the name column; refine balloon text and schema data in Earth or a GIS tool when you need richer descriptions.

Name vs description in KML placemarks

In KML, <name> is the short label in the sidebar and often beside the pin. <description> is the richer balloon content—HTML, notes, links—that appears when a user inspects the placemark. Spreadsheet authors often keep both a name column and a longer notes or description column in CSV.

This tool prioritizes getting pins on the map with a reliable <name> from name/title/label. That matches the usual first need: find the right pin quickly among dozens of sites. Long-form description balloons, ExtendedData, and styled HTML are easy to add later in Google Earth once positions are correct.

If your sheet’s “description” column holds the only human-readable identity, rename or copy it to name before converting. Empty or generic names force reviewers to click pins blindly. Keep description-style paragraphs in the CSV for ops, then paste key lines into Earth balloons after spatial QA passes.

Coordinate order: CSV lat/lon vs KML lon,lat

People say “lat/lon” in conversation and often store latitude in the first coordinate column. KML’s <coordinates> grammar is longitude,latitude[,altitude]—the opposite order of that habit. A San Francisco trailhead might be latitude 37.7749 and longitude −122.4194 in CSV, but −122.4194,37.7749,0 inside KML.

The converter performs that reordering for you when writing the Point. You should still label CSV columns correctly so the numeric values land in the right fields. Mislabeling (putting longitude numbers under a latitude header) produces confidently wrong pins.

Altitude is written as 0 for these Point placemarks—suitable for clamp-to-ground style 2D lists. If you need real elevations, edit altitude in a GIS workflow or post-process the KML; do not assume a CSV altitude column is automatically applied in this path.

WGS 84 decimal degrees only

KML geographic coordinates are WGS 84 longitude/latitude. Your CSV should already be in decimal degrees on that datum—the same numbers you would paste into Google Maps’ search box for a point.

Projected coordinates (Web Mercator meters, UTM easting/northing, state plane) will not magically become degrees. A value like 500000 in a “longitude” cell is a projection red flag. Reproject in QGIS or your geocoder before converting.

Avoid DMS strings (37°46'29"N) and hemisphere letters inside the coordinate cells. Normalize to signed decimals first—negative west longitudes and south latitudes—so Number parsing succeeds and rows are not skipped.

Rows skipped and empty Documents

Any row whose latitude or longitude is missing, blank, or not a finite number is omitted. That prevents a spray of pins at 0,0 in the Gulf of Guinea from bad cells—a common embarrassment in rushed exports.

If every row fails validation, you may get a Document with no Placemarks. Earth then looks empty or complains. Fix the sheet, confirm headers, and reconvert; do not assume a silent skip means “Earth will interpolate.”

Compare expected pin count to CSV length after cleaning. Geocoding failures often leave empty lat/lon cells; those rows need addresses fixed upstream, not forced into KML.

Points only—not paths or polygons

One CSV row with a single lat/lon pair is naturally a Point. Building a LineString needs an ordered list of vertices; a Polygon needs rings. Those structures do not fall out of a simple rectangular table without extra conventions (WKT columns, GeoJSON geometry, or multi-row path IDs).

This converter does not invent path or polygon KML from flat coordinate columns. If your deliverable is a route corridor or parcel outline, author geometry in GIS and export KML/KMZ from there, or use formats designed for full geometry interchange.

For mixed workflows, export points here for pins, and keep polygon layers in a separate GeoJSON or shapefile pipeline. Merging everything into one overloaded CSV usually creates ambiguous columns and broken expectations.

Plain KML vs KMZ packaging

KML is XML text. KMZ is a zip archive that typically contains a doc.kml plus optional icons, overlays, and supporting files. Google Earth opens both; for a Document of Point placemarks with default styling, plain KML is enough.

This converter outputs KML markup you can save as .kml and open immediately. You do not need to zip it into KMZ for basic pin viewing. Skip KMZ unless you must bundle custom icon hrefs, screen overlays, or other assets Earth should load from the package.

If a recipient insists on .kmz, you can zip your .kml locally after conversion—but that packaging is optional, not required by this tool or by Earth for simple placemarks. Prefer sharing .kml when email filters treat .kmz like opaque binaries and reviewers want to peek at the XML.

Excel, Sheets, and geocoding prep

Before converting, ensure Excel did not turn coordinates into dates or strip precision. Widen columns and show enough decimal places for street-level pins—six decimals is a common working precision, though your source accuracy may be lower.

If lat/lon arrived as a single “location” column, split them in the Online CSV Editor or Sheets first. Combined strings like "37.77, -122.42" are not auto-detected as two coordinate headers.

Geocode addresses in a dedicated step, write decimal lat/lon columns, then convert. Do not expect the KML tool to geocode street text—it only maps existing numeric coordinates into Placemarks.

Typical workflows

Retail and facilities: export store master CSV → convert to KML → review coverage in Earth with the ops lead.

Field survey: log waypoints in a form that exports CSV → convert → hand .kml to a PM who lives in Earth.

Round-trip cleanup: KML to CSV for spreadsheet edits → fix names and bad coordinates → CSV to KML back to Earth.

Event logistics: stages, gates, and first-aid posts maintained in Sheets become a volunteer-facing Earth layer in minutes.

Browser privacy and large pin lists

Generation is local. Pasted or uploaded CSV is not sent to Convert CSV servers for the KML transform. Site analytics and advertising follow the privacy policy separately.

Thousands of rows can slow a tab while XML is built and previewed. Filter to the sites you need, or convert regional batches, when the browser struggles.

Location lists often encode homes, unreleased projects, or critical infrastructure. Client-side conversion still requires care about who receives the .kml and where copies are stored.

Round-trip with KML to CSV

The natural reverse tool is KML to CSV: Earth placemarks become name and coordinate columns again. Teams alternate—edit in Sheets when attributes change, edit in Earth when spatial review is easier—then convert back.

Round-trips preserve the tabular core (labels and lat/lon) better than styles, folders, and camera views. Re-apply icons and folder organization in Earth after import when presentation matters.

Keep explicit latitude and longitude column names on the CSV side so neither direction has to guess axis order. After each hop, spot-check a known pin before distributing the file.

Quality checklist before you share the KML

Confirm headers were detected, pin count matches valid coordinate rows, and one landmark sits in the right city. Open the .kml in Earth yourself before emailing it.

Note whether altitude-at-zero 2D pins are acceptable, and keep the source CSV until stakeholders sign off.

Lat/lon headers detected; values not swapped.
Meaningful name/title/label column present.
Skipped rows understood and fixed or accepted.
Points-only scope matches the deliverable.
Plain .kml sufficient (KMZ not required).

Frequently asked questions

What column names does the converter detect for coordinates?

It looks for latitude or lat, and for longitude, lon, lng, or long, matched case-insensitively. Rename unconventional headers (for example x/y or coord_x) before converting.

How are placemark names chosen?

A column named name, title, or label (case-insensitive) supplies each placemark’s <name>. If none of those headers exist, placemarks are labeled Placemark 1, Placemark 2, and so on.

Does my CSV description column become KML <description> balloons?

This converter focuses on Point placemarks with a reliable <name> plus coordinates. Put the sidebar label in a name/title/label column; add richer balloon HTML or notes in Google Earth after positions check out, or keep long notes in the spreadsheet for ops.

Why does KML list longitude before latitude?

That order is part of the KML/OGC <coordinates> convention. Your CSV can keep separate latitude and longitude columns; the converter writes lon,lat,altitude in the XML so Earth interprets axes correctly.

What happens to rows without valid coordinates?

They are skipped and do not appear as placemarks. Fix blank or non-numeric cells, then convert again if those sites should appear on the map.

Can I create polygons or paths from CSV?

No. Each valid row becomes one Point placemark. For LineString or Polygon KML, use GIS software or another geometry-aware workflow.

Do I need to package the output as KMZ?

No. Plain .kml with Point placemarks opens in Google Earth. KMZ is only needed when you must zip icons, overlays, or other assets with the document.

Is my CSV uploaded to a server?

No. KML is generated in your browser. See the Privacy Policy for site analytics and advertising.

How do I get placemarks back into a spreadsheet?

Use the KML to CSV converter on this site to extract names and coordinates from an existing .kml (unzip KMZ first if needed).

What altitude do the placemarks use?

Point coordinates are written with altitude 0 for simple 2D pins. Edit altitude in a GIS or Earth workflow if you need real elevations.

What coordinate reference system should I use?

WGS 84 decimal degrees—the geographic lat/lon KML expects. Do not paste projected meters into the latitude/longitude columns.

Why do pins show up in the wrong country?

Almost always swapped latitude and longitude in the CSV. Check ranges (−90…90 for latitude, −180…180 for longitude), swap columns if needed, and reconvert.

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.

CSV to KML Converter

Input

Output Preview