CSV to GeoJSON Converter Online Free

CSV to GeoJSON Converter

Spreadsheets are where store lists, survey pins, and asset inventories usually live. Maps want GeoJSON: a FeatureCollection of Point features with coordinates and properties. This free CSV to GeoJSON converter turns rows with latitude and longitude columns into map-ready JSON you can drop into Leaflet, Mapbox, QGIS, geojson.io, or any tool that speaks RFC 7946 GeoJSON.

Paste CSV or upload a .csv file. The tool detects latitude and longitude columns, builds one Point feature per row, and copies every other column into that feature’s properties object. Output is a FeatureCollection — not a bare Geometry or a single Feature — so it matches what most web maps and GIS importers expect. Conversion runs in your browser; the CSV is not uploaded to a server as part of the transform.

Below you will find how lat/lon columns are recognized, why GeoJSON stores coordinates as [longitude, latitude], what happens to blank or invalid coordinates, CRS and WGS84 assumptions, Excel cleanup before convert, performance for large pin lists, the reverse path with GeoJSON to CSV, and a full troubleshooting and FAQ section for real spreadsheet-to-map workflows. Use the preview as your source of truth before you download or publish the layer.

Key features

Builds a standard GeoJSON FeatureCollection with one Point feature per CSV data row.
Reads dedicated latitude and longitude columns and writes coordinates in GeoJSON order [longitude, latitude].
Copies all other columns into each feature’s properties object for labels, filters, and popups.
Accepts pasted CSV or uploaded .csv files matching common spreadsheet exports from Excel and Google Sheets.
Produces output ready for Leaflet, Mapbox GL, QGIS, geojson.io, and most GeoJSON-aware APIs.
Runs entirely in the browser so location rows are not sent to a server for conversion.
Pairs with GeoJSON to CSV on this site for round-trips when Point geometry is the whole story.

About the CSV with latitude and longitude columns to GeoJSON format

CSV is a flat grid: one header row, one data row per place. GeoJSON encodes geography as JSON. The shape this converter produces is a FeatureCollection: a top-level object with type FeatureCollection and a features array. Each Feature has type Feature, a properties object (your non-coordinate columns), and a Point geometry whose coordinates array is [longitude, latitude] in decimal degrees — GeoJSON order, not the lat-first order many spreadsheet users expect when reading pairs aloud.

Latitude and longitude must appear as dedicated columns (commonly named latitude/longitude, lat/lon, y/x, or similar recognizable headers). Those columns drive the geometry and are not duplicated as ordinary properties unless your workflow expects them there. Every other header becomes a property key on the feature. Rows with missing or non-numeric coordinates typically cannot become valid Points — fix or filter those rows before publishing a map layer.

This path builds Points only. It does not reconstruct LineString or Polygon rings from two columns. If you previously flattened polygons with GeoJSON to CSV, converting that CSV back yields Pins, not the original boundaries. Keep the original GeoJSON whenever rings and topology still matter.

How it works

The converter parses the CSV header and rows. It identifies which columns represent latitude and longitude (by common header names and conventions). Remaining columns are treated as attribute fields. Each data row becomes one GeoJSON Feature: type Feature, properties filled from the attribute columns, and geometry set to a Point.

Coordinate assembly follows the GeoJSON specification: the geometry.coordinates array is [longitude, latitude]. Spreadsheet column order does not change that — even if your CSV lists latitude before longitude, the JSON array still stores longitude first. Values are read as decimal degrees for standard WGS84 maps.

Features are collected into a FeatureCollection and pretty-printed or downloadable as .geojson / .json. There is no geocoding step: addresses without lat/lon are not looked up. There is no reprojection, buffering, or clustering — only tabular rows to Point features.

Common use cases

Publishing a store or depot list from Excel as a FeatureCollection for a Leaflet or Mapbox map.
Turning a field-survey CSV of pins into GeoJSON for QGIS or a web map review.
Converting an open-data spreadsheet of lat/lon assets into GeoJSON for a public portal.
Rebuilding cleaned Point features after editing attributes in Sheets or the Online CSV Editor.
Preparing geocoded address exports as GeoJSON for a delivery or logistics dashboard.
Handing developers a FeatureCollection instead of a spreadsheet when an API or static map needs JSON.

How to use this tool

Prepare a CSV with clear latitude and longitude columns (decimal degrees) plus any attribute columns you want on the map.
Paste the CSV or upload a .csv file into the converter.
Confirm the preview FeatureCollection: feature count should match data rows, and a known pin’s coordinates should look right.
Check that property keys match your headers and that lat/lon were not left as the only useful fields by accident.
Copy or download the GeoJSON for your map library, GIS tool, or API — and keep the CSV if you still need spreadsheet edits.

Example

Input CSV

name,latitude,longitude
Store A,40.7484,-73.9857

Output GeoJSON

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": { "name": "Store A" },
      "geometry": { "type": "Point", "coordinates": [-73.9857, 40.7484] }
    }
  ]
}

Tips for best results

Name latitude and longitude columns clearly before converting — ambiguous headers cause missed geometry.
Remember GeoJSON coordinates are [longitude, latitude]; verify a known city pin after download.
Use decimal degrees in WGS84 (EPSG:4326). Do not paste projected easting/northing as if they were lat/lon.
Filter or fix blank coordinate rows in the sheet before convert so every feature is a valid Point.
Keep attribute columns as simple scalars — nested JSON-in-a-cell does not become nested properties automatically.
Spot-check feature count against CSV row count (minus the header) in the preview.
Use GeoJSON to CSV when you need the reverse path from a FeatureCollection back to a spreadsheet.
Keep the source CSV until a few sample Points land correctly on a basemap.

Common errors and how to fix them

The output has no features, or rows are skipped, even though the CSV has data.: Confirm the file has a header row and recognizable latitude/longitude column names with numeric decimal-degree values. Blank, missing, or non-numeric coordinates cannot produce valid Points — clean those cells in the sheet and convert again.
Pins appear in the wrong place (ocean, wrong country) on the map.: Latitude and longitude were likely swapped in the CSV, or you are reading GeoJSON [lon, lat] as if it were lat-first. Verify a known landmark: a Manhattan pin should be near latitude 40.75 and longitude -73.99. Fix the source columns, then reconvert.
I expected polygons or routes, but every feature is a Point.: This tool only builds Point geometries from lat/lon columns. Flat CSV cannot carry full rings or vertex lists. For lines and polygons, author GeoJSON in a GIS tool or keep the original FeatureCollection from before any flatten to CSV.
Property values look wrong (leading zeros gone, dates changed) in the GeoJSON.: That usually happened in Excel or Sheets before conversion. Re-export CSV with text formatting for IDs and stable ISO dates, then convert again. The GeoJSON properties mirror whatever cell text the CSV contained.
The conversion is slow or the tab becomes unresponsive on a large file.: Tens of thousands of simple Points are often fine; huge sheets with wide attribute sets can still stress memory when building a large JSON tree. Split the CSV, drop unused columns, or convert a sample first to validate schema.
My map library rejects the file or shows nothing.: Confirm the root type is FeatureCollection and that coordinates are numbers, not strings with degree symbols. Ensure you are loading the downloaded GeoJSON (not the CSV) and that the map’s expected CRS is WGS84 lon/lat.

Best practices

Use clear headers such as latitude and longitude (or lat/lon) and decimal degrees in WGS84 before converting.
Validate a few known Points on a basemap after every conversion — especially after anyone edits the sheet.
Remove or fix rows with blank coordinates rather than publishing incomplete Features.
Keep property columns simple and consistent; rename cryptic GIS field names for map popups.
Document that the layer is Points-only when sharing with teammates who might expect boundaries.
Retain the source CSV for attribute edits; regenerate GeoJSON when the sheet changes instead of hand-editing JSON.
Round-trip with GeoJSON to CSV only when Point geometry is acceptable on the way back.

What CSV to GeoJSON conversion actually does

Spreadsheets think in rows and columns. Maps think in features: a geometry plus a bag of attributes. This conversion takes each CSV data row, builds a Point from latitude and longitude, and puts every other column into properties. The result is a FeatureCollection you can style, filter, and display without a desktop GIS license.

You keep the tabular story — names, categories, statuses, counts — and a precise pin for each row that had valid coordinates. You do not get styling, tile URLs, or interactive behavior inside the file; those live in your map app. You also do not get lines or polygons from two numeric columns alone.

It is not a geocoder and not a full GIS engine. There is no address lookup, dissolve, buffer, or spatial join. If you only have street addresses, geocode first (or obtain lat/lon another way), then convert. If you need topology and boundaries, stay in a spatial format end to end.

When to convert CSV to GeoJSON

Convert when stakeholders maintain locations in Excel or Sheets but developers need FeatureCollections; when a geocoder or survey app exported lat/lon CSV and you want a web map; when you cleaned attributes in a spreadsheet after a GeoJSON to CSV pass and need Points back; or when a BI export already has coordinates and a static map is the next step.

Skip conversion if the portal already offers GeoJSON and you have not changed the attributes. Skip if you need MultiPolygon parcels or route LineStrings — author those in GIS. Skip if coordinates are missing and you hoped the tool would invent them from an address column.

A practical pattern: keep CSV as the editable source of truth for pin inventories, regenerate GeoJSON for publish, and use GeoJSON to CSV only when non-GIS teammates need a fresh spreadsheet extract.

Good fit: store locators, survey pins, asset inventories, geocoded open-data tables.
Poor fit: cadastral boundaries, road networks, or any layer where rings and paths are the data.
Better as a script: nightly ETL of multi-million-row national pin dumps into a spatial warehouse.

Latitude and longitude columns

The converter needs dedicated coordinate columns. Common header names include latitude, longitude, lat, lon, lng, and similar variants. If your sheet uses cryptic names (Y_COORD / X_COORD), rename them to latitude and longitude before converting so detection is unambiguous.

Values should be decimal degrees: roughly latitude −90 to 90 and longitude −180 to 180 for global WGS84 data. Degree-minute-second text, hemisphere letters without numeric conversion, or projected meters will not plot correctly on standard web basemaps.

Column order in the CSV does not redefine GeoJSON array order. You may list latitude before longitude in the sheet; the geometry.coordinates array is still [longitude, latitude]. Always verify with a known pin after the first convert.

GeoJSON coordinate order: longitude, then latitude

RFC 7946 GeoJSON stores Point coordinates as [longitude, latitude] — the opposite of the “lat, lon” phrase many people say aloud and the opposite of some older APIs. This is the single most common source of “my points are in the ocean” bugs.

When you open the output JSON, expect something like coordinates: [-73.9857, 40.7484] for a Manhattan landmark: longitude first (negative in the western hemisphere), latitude second. Map libraries that consume GeoJSON already expect that order; do not swap again when loading the file.

If a teammate pastes coordinates into documentation, label them explicitly as lon/lat or lat/lon. Ambiguous pairs in chat are how swapped columns re-enter the CSV weeks later.

Other columns become properties

Every non-coordinate header becomes a key in the feature’s properties object. A row with name, status, and capacity yields properties { name, status, capacity } next to the Point geometry. Those properties power popups, filters, and thematic styling in your map stack.

Keep values scalar when you can: strings, numbers, simple booleans-as-text. Nested objects stuffed into one CSV cell do not automatically become nested JSON properties. Flatten address fields into address_city and address_zip style columns if your map needs structured attributes.

Empty cells typically become empty strings or omitted-looking values depending on normalization — decide whether your map code treats blank status as “unknown” or skips the feature. Consistent headers across all rows matter: CSV already has a fixed schema, which is an advantage over heterogeneous GeoJSON property bags.

Points only: what this path cannot rebuild

Two columns define a pin, not a boundary. LineString paths and Polygon rings require ordered vertex lists that flat CSV does not carry alongside ordinary attributes without complex conventions. This converter intentionally emits Point geometries only.

If you used GeoJSON to CSV earlier and only kept a representative coordinate for polygons, CSV to GeoJSON will create Points at those proxies. The original rings are gone unless you still have the source GeoJSON or a spatial database.

Plan round-trips accordingly: Point inventories round-trip cleanly; cadastral and network data do not. Archive full-geometry files separately from spreadsheet attribute workflows.

Coordinate reference systems and WGS84

Standard GeoJSON assumes WGS84 longitude and latitude in decimal degrees (EPSG:4326). Web maps and this converter’s consumers almost always expect that. If your CSV came from a local projected grid (state plane, UTM meters) and the columns are still labeled lat/lon, the numbers will look “fine” in the sheet and wrong on the globe.

Reproject to EPSG:4326 in QGIS or a script before converting when you know the source is projected. Document the CRS in a README when sharing either the CSV or the GeoJSON with map consumers.

Altitude as a third coordinate is uncommon in simple inventories. This path focuses on the horizontal lon/lat pair. Preserve 3D needs in specialized formats or extended GeoJSON authored outside this flow.

Preparing CSV in Excel and Google Sheets

Before converting, freeze a clean header row, delete totally empty rows, and ensure lat/lon cells are numeric — not text with degree symbols or commas as decimal separators in locales that need normalization. Export or download as CSV (UTF-8 when non-ASCII place names matter).

Watch Excel’s habit of eating leading zeros on IDs and auto-converting values that look like dates. Format identifier columns as Text before export if those IDs must survive into properties. Confirm the delimiter is comma if your locale defaults to semicolon — a mis-delimited file will scramble columns and coordinates.

Use the Online CSV Editor on this site to rename headers, drop unused columns, and filter blank coordinate rows before the GeoJSON step. A tidy sheet converts into a tidy FeatureCollection.

Invalid rows, blanks, and quality control

Not every spreadsheet row is map-ready. Missing latitude, missing longitude, or values like N/A and TBD should be fixed or excluded. Publishing Features with null geometry or nonsense coordinates creates confusing empty maps and support tickets.

After conversion, compare features.length to the number of data rows you expected. Spot-check min/max latitude and longitude — a max latitude of 400 usually means a swapped or mistyped column. Plot a sample in geojson.io before handing the file to production.

When only a subset of rows geocoded successfully upstream, separate “mapped” and “unmapped” sheets so the FeatureCollection stays clean and the remapping queue stays obvious.

Large files, browser limits, and performance

Parsing and JSON construction run client-side. Simple Point lists in the low tens of thousands of rows are often comfortable on modern devices. Extremely wide attribute tables or hundreds of thousands of rows can stall the tab when the stringified FeatureCollection grows large.

Practical mitigations: drop unused property columns; split by region or category; convert a schema sample first; use a local script (Python, Node) for recurring warehouse-scale exports. There is no fixed server quota for the transform — the limit is device memory and patience.

If the tab freezes, reduce the file and retry. For automated pipelines, browser paste boxes are the wrong runtime; keep this tool for interactive cleanup and small-to-medium publish jobs.

Using the GeoJSON in maps and GIS

Web: load the FeatureCollection in Leaflet (L.geoJSON), Mapbox GL (GeoJSON source), OpenLayers, or any library that accepts GeoJSON. Bind popups to properties.name or whatever fields you included.

Desktop: drag the .geojson into QGIS or similar. Confirm the layer CRS is EPSG:4326 and that labels use property fields. Export to other spatial formats from GIS if a downstream system needs Shapefile or GeoPackage.

APIs and static hosting: many map backends accept a FeatureCollection document as a file or request body. Validate JSON parse and feature count in CI when the layer is part of a release.

Privacy, sensitive locations, and client-side processing

Conversion happens in your browser. CSV content is not sent to Convert CSV servers as part of the transform. Site analytics and advertising follow the privacy policy separately from the conversion pipeline.

Location rows are often sensitive: customer homes, health visits, employee sites, or protected-species sightings. Even with local conversion, control who receives the GeoJSON, reduce precision when policy requires it, and avoid pasting confidential sheets on shared machines carelessly.

Published map tiles and public Git repos are easy to scrape. Treat a FeatureCollection of real-world pins with the same care you would give the spreadsheet of addresses it came from.

Reverse path: GeoJSON to CSV

When you need spreadsheet analysis again, use the GeoJSON to CSV converter. It flattens FeatureCollection properties into columns and extracts latitude and longitude for Points (with representative coordinates for some non-point types).

Round-tripping Points through CSV and back to GeoJSON is a normal cleanup loop: edit attributes in Sheets, reconvert to GeoJSON, republish. Round-tripping polygons through a representative-point CSV loses boundaries — do not use that loop when rings matter.

Keep naming consistent (latitude / longitude) on the CSV side so the return trip to GeoJSON detects columns reliably.

Quality checklist before you publish the GeoJSON

Confirm feature count, coordinate order on a known pin, property keys for popups, and WGS84 decimal degrees. Open the file in the target map library or geojson.io before calling the layer done.

Record source CSV name, export date, and CRS assumption when the layer informs a decision. Keep the CSV until the map is signed off.

Latitude and longitude columns numeric and in plausible ranges.
Sample Point lands correctly on a basemap (not swapped).
properties contain the attributes your UI expects.
No reliance on this file for polygon/line geometry.
Sensitive locations reviewed under your data policy.

Frequently asked questions

What GeoJSON structure does this converter produce?

A FeatureCollection whose features are Point geometries. Each CSV data row becomes one Feature with properties from the non-coordinate columns and coordinates as [longitude, latitude].

Why is longitude first in the coordinates array?

The GeoJSON specification (RFC 7946) defines Point coordinates as [longitude, latitude]. Spreadsheet columns may still be labeled latitude and longitude separately; only the JSON array uses lon-first order.

Which column names work for coordinates?

Clear names such as latitude and longitude (or common short forms like lat and lon) work best. Rename cryptic headers before converting so the tool can detect the coordinate fields reliably.

Can it create Polygon or LineString features from CSV?

No. This path builds Points from latitude and longitude columns only. Full paths and rings need a GIS workflow or an original GeoJSON that still contains those geometries.

Is my CSV uploaded anywhere?

No. Parsing and FeatureCollection construction happen entirely in your browser. See the Privacy Policy for site analytics and advertising.

How do I go from GeoJSON back to a spreadsheet?

Use the GeoJSON to CSV converter, which flattens feature properties into columns and extracts latitude and longitude for mapping back into tables.

Does the tool geocode street addresses?

No. It only uses numeric latitude and longitude columns already present in the CSV. Geocode addresses in a separate step first if you only have street text.

What coordinate system should I use?

Standard GeoJSON expects WGS84 decimal degrees (EPSG:4326). Reproject projected easting/northing data before converting if you want pins to land correctly on web maps.

What happens to rows with blank latitude or longitude?

Rows without valid numeric coordinates cannot become reliable Point features. Fix or filter those rows in the spreadsheet before converting for a clean map layer.

Will my other CSV columns appear on the map?

Yes — non-coordinate columns are copied into each feature’s properties object, which map libraries use for popups, labels, and filters.

Is there a file size or row limit?

There is no fixed server quota because conversion is client-side, but very large sheets can slow or freeze the browser. Split files or drop unused columns when the CSV is huge.

Can I round-trip polygons through CSV and back?

Not losslessly. Flattening polygons to a representative point and converting CSV back yields Points, not the original rings. Keep the original GeoJSON when boundaries 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.

CSV to GeoJSON Converter

Input

Output Preview