GeoJSON to CSV Converter Online Free

GeoJSON to CSV Converter

GeoJSON is the web’s common language for places: store pins, census tracts, bike routes, and survey points all travel as JSON with geometry attached. Spreadsheets and BI tools rarely speak that language natively. This free GeoJSON to CSV converter flattens a FeatureCollection into spreadsheet rows so you can filter attributes, chart metrics, and hand data to Excel, Google Sheets, Tableau, or Power BI without a GIS license.

Paste a FeatureCollection or upload a .geojson / .json file. The tool maps each feature’s properties to columns, adds a geometry_type column, and extracts coordinates for mapping back into tables: Point features get dedicated latitude and longitude columns; LineString, Polygon, MultiPoint, and other non-point types get a representative coordinate pair so every row still has a usable location without dumping every vertex into the sheet. Conversion runs in your browser — the GeoJSON is not uploaded to a server as part of the transform.

Below you will find how FeatureCollections differ from bare Features, how property keys become headers across inconsistent features, what “representative coordinate” means for lines and polygons, Excel pitfalls after download, performance notes for large files, the reverse path with CSV to GeoJSON, and a full troubleshooting and FAQ section for real map-to-spreadsheet workflows. Use the preview as your source of truth before you download or share the file.

Key features

Scans every feature’s properties first so the full union of keys becomes headers and missing keys stay blank rather than misaligning rows.
Adds a geometry_type column automatically so you can filter or group by Point, LineString, Polygon, and other types after export.
Writes dedicated latitude and longitude columns for Point geometries using GeoJSON’s [longitude, latitude] coordinate order correctly.
Extracts a representative coordinate pair for multi-point, line, and polygon geometries instead of skipping non-point features.
Accepts a standard FeatureCollection matching the shape produced by most GIS exports, Mapbox, Leaflet layers, and public open-data portals.
Runs entirely in the browser so map attribute data is not sent to a server for conversion.
Produces standard CSV ready for Excel, Google Sheets, BI tools, or the reverse CSV to GeoJSON converter on this site.

About the GeoJSON to CSV format

GeoJSON encodes geography as JSON. The shape this converter expects is a FeatureCollection: a top-level object with type FeatureCollection and a features array. Each Feature typically has type Feature, a properties object (attribute data), and a geometry object (type plus coordinates). CSV is a flat grid: one header row, one data row per feature.

Property keys become column headers. The converter first scans every feature’s properties so the union of keys defines the column set — a feature missing a key gets a blank cell instead of shifting later columns. Geometry is summarized, not fully serialized: a geometry_type column records Point, LineString, Polygon, MultiPolygon, and so on. For Point geometries, longitude and latitude are written as separate columns (GeoJSON stores coordinates as [longitude, latitude]; the CSV flips them into the lat/lon columns analysts expect). For non-point geometries, a representative coordinate pair is extracted so the row still has a location anchor without exploding rings and paths into hundreds of columns.

A bare Geometry, a lone Feature, or a Topology JSON file from topojson is not a FeatureCollection. Wrap a single Feature as { "type": "FeatureCollection", "features": [ yourFeature ] } before converting. Nested objects inside properties may stringify or flatten depending on how values are normalized — prefer simple scalar properties when you control the export.

How it works

The converter parses the pasted or uploaded text as JSON and requires a top-level FeatureCollection with a features array. It rejects or yields empty results when the root is only a Geometry or a single Feature without that wrapper. It then walks every feature’s properties object to collect the complete set of property keys — the same union-of-keys strategy used by JSON-to-tabular tools — so heterogeneous attributes still form one coherent header row.

For each feature, property values are mapped into those columns. The geometry’s type string is written to geometry_type. Coordinate extraction branches on geometry type: Point geometries copy the coordinate pair into longitude and latitude columns (remembering GeoJSON order is longitude first). LineString, MultiPoint, Polygon, MultiLineString, MultiPolygon, and similar types contribute a representative coordinate — typically an early vertex or ring point — so the spreadsheet still has a map-able pin without storing every vertex.

Values are normalized for spreadsheet cells (nulls and missing keys become empty cells; nested structures may appear as text). The result is escaped as CSV and shown in a preview you can copy or download. Nothing is executed as a spatial query — there is no buffering, reprojection, or true centroid calculation in this path.

Common use cases

Analyzing census tract or administrative boundary properties exported as GeoJSON in a spreadsheet.
Extracting store or depot location data from a GeoJSON API response for a retail or logistics audit.
Converting an open-data GeoJSON dataset into CSV for a Tableau or Power BI import.
Reviewing survey or field-collection point properties from a mobile GIS or ODK-style export.
Filtering map layers by attribute (status, category, year) after flattening to CSV for non-GIS teammates.
Spot-checking geocoded address lists or delivery pins before publishing them back to a map.

How to use this tool

Paste your GeoJSON FeatureCollection or upload a .geojson / .json file. If you only have a single Feature, wrap it in a FeatureCollection first.
Confirm the preview row count roughly matches features.length and that property columns look familiar.
Check geometry_type values and sample latitude/longitude cells — especially for a known Point you can verify on a map.
For line or polygon layers, remember coordinates are representative only; keep the original GeoJSON for boundary work.
Copy or download the CSV for spreadsheet analysis, BI import, or a later round-trip with CSV to GeoJSON.

Example

Input GeoJSON

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

Output CSV

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

Tips for best results

Confirm the root type is FeatureCollection with a features array — bare Feature or Geometry objects need wrapping first.
Property keys become headers; keep keys consistent across features when you control the source to avoid sparse columns.
Treat latitude/longitude on non-Point rows as a representative location, not the full path or polygon boundary.
Use the geometry_type column to filter Points vs Polygons after download before charting.
For files over a few megabytes, pre-filter features in QGIS, geojson.io, or a small script before converting.
Spot-check lon/lat order against a known city pin — GeoJSON is [lon, lat], CSV columns are labeled latitude and longitude.
Use CSV to GeoJSON when you need the reverse path from spreadsheet columns back to a FeatureCollection.
Keep the original .geojson until row counts and a few sample coordinates look right in the preview.

Common errors and how to fix them

The tool rejects the input or produces no rows, saying it is not a valid FeatureCollection.: A bare Geometry object or a single Feature (not wrapped in a FeatureCollection with a features array) is not supported directly. Wrap a single feature as { "type": "FeatureCollection", "features": [ yourFeature ] } before converting. Also confirm the JSON parses (no trailing commas, no comments).
Polygon or LineString features only produce one coordinate pair instead of the full boundary or path.: This is expected. Flat CSV cannot hold rings and vertex lists cleanly alongside attributes. The converter extracts a representative point for non-Point geometries so every row still has a location. For full boundary analysis, keep working with the original GeoJSON in a GIS tool.
Some rows have blank values for a property that other rows have.: That feature’s properties object simply does not include that key. GeoJSON does not require identical schemas across features. Blank cells mean “absent,” not a shifted column — the converter built headers from the union of all keys first.
The conversion is slow or the tab becomes unresponsive on a large file.: Very large FeatureCollections with thousands of complex polygon geometries are memory-intensive to parse in the browser. Filter to the features you need, drop unused properties, or split the file into smaller chunks in QGIS or a script before converting.
Latitude and longitude look swapped compared to my map.: GeoJSON coordinates are always [longitude, latitude]. The CSV columns are labeled latitude and longitude separately. If a pin lands in the ocean near (lat, lon) = (lon, lat) of your city, you may have been reading raw GeoJSON arrays as lat-first. Trust the labeled CSV columns and verify against a known Point.
Nested property objects show up as odd text or empty cells.: CSV is flat. Nested objects and arrays inside properties do not become sub-tables. Flatten or stringify properties in your GIS export (or simplify the schema) before conversion if you need clean scalar columns.

Best practices

Confirm your file is a FeatureCollection (not a bare Feature or Geometry) before pasting it in.
For polygon-heavy datasets, treat extracted coordinates as representative locations only — keep the original GeoJSON for spatial analysis, area, and topology.
Keep property keys consistent across features when you control the source to avoid sparse columns and confusing blanks.
For files over a few megabytes, pre-filter to relevant features or bounding boxes using a GIS tool or script before converting.
Use geometry_type filters in the spreadsheet to separate pins from areas before building charts that assume point data.
Document the CRS assumption: standard GeoJSON is WGS84 (EPSG:4326). Do not mix projected coordinates without documenting them.
Round-trip carefully: CSV to GeoJSON rebuilds Points from lat/lon columns — it will not restore full polygon rings lost in the flatten.

What GeoJSON to CSV conversion actually does

GIS tools think in features: a geometry plus a bag of attributes. Spreadsheets think in rows and columns. This conversion takes each Feature in a FeatureCollection and writes one CSV row: attributes become cells under property-named headers, geometry becomes a type label plus coordinate columns suitable for tables and BI tools.

You keep the tabular story — names, categories, counts, statuses — and a usable location for Points (and a pin-like proxy for other shapes). You do not keep styling, tile URLs, or interactive map behavior. That is usually what analysts want when the question is “filter by region code and sum revenue,” not “edit the polygon ring.”

It is not a full GIS engine. There is no dissolve, buffer, spatial join, or on-the-fly reprojection. If your workflow needs those, convert attributes here for review, then return to QGIS, PostGIS, or your mapping stack for geometry-heavy work.

When to convert GeoJSON to CSV

Convert when an open-data portal or API only ships GeoJSON and your stakeholders live in Excel; when a field app exports FeatureCollections and you need a quick attribute audit; when a BI tool imports CSV more reliably than GeoJSON; or when you want to share map attributes with teammates who will not open a GIS.

Skip conversion if you need topology, exact polygon area, or every vertex — stay in GeoJSON or a spatial database. Skip if the file is already a simple CSV with lat/lon and no geometry nesting. Prefer the official tabular download when a portal offers both GeoJSON and CSV and you only need attributes.

A practical pattern: download GeoJSON for the map, convert a filtered subset to CSV for the spreadsheet review, then use CSV to GeoJSON only when you intentionally rebuild Point features from cleaned columns.

Good fit: point inventories, store locators, survey pins, attribute-heavy open data with simple geometries.
Poor fit: detailed cadastral MultiPolygons when every ring vertex matters for legal boundaries.
Better as a script: nightly ETL of multi-gigabyte national layers into a warehouse.

FeatureCollection vs Feature vs Geometry

GeoJSON defines several root types. FeatureCollection is a container: type FeatureCollection plus features: [ ... ]. That is what almost every GIS “export layer” and Mapbox/Leaflet dump produces, and what this converter requires.

A Feature is one record: properties + geometry. Pasting a lone Feature fails the FeatureCollection check. Wrap it: put the Feature inside a features array under a FeatureCollection root. A Geometry alone (just type and coordinates) has no properties and is not a feature list — wrap it as a Feature first, then as a FeatureCollection, if you truly need a CSV row.

Confusion often comes from APIs that return a single Feature for “get by id” and a FeatureCollection for “search.” Always check the top-level type field before pasting. Topology JSON (TopoJSON) is a different format entirely and must be converted to GeoJSON first.

Properties become columns

Every key in a feature’s properties object is a candidate CSV header. The converter unions keys across all features so the sheet schema is complete. Feature A with { name, status } and Feature B with { name, capacity } yields columns name, status, capacity — B’s status cell is blank, A’s capacity cell is blank.

That sparse-grid behavior matches real-world GeoJSON: schemas are often soft. Downstream, rename headers, drop empty columns, or fill defaults in the Online CSV Editor before publishing. When you author data, prefer consistent keys so blanks mean “unknown” rather than “this export forgot the field.”

Nested properties (objects or arrays) fight CSV. A properties.address object does not become address.city and address.zip automatically in every path — flatten at export (many GIS tools have “include attributes only” or field calculators) if you need tidy columns. IDs that look numeric should be watched in Excel so leading zeros survive.

Point geometries: latitude and longitude columns

For geometry.type Point, coordinates are a two-element array [longitude, latitude] in WGS84 for standard GeoJSON. The converter writes separate latitude and longitude columns so spreadsheet users can sort, filter, and feed charting tools without decoding JSON arrays.

Verify with a landmark: a Manhattan store near Empire State should land near latitude 40.75 and longitude -73.99, not the swapped pair. If your source incorrectly stored lat-first inside the GeoJSON coordinates array, the file itself is non-compliant — fix upstream; do not “correct” by swapping CSV labels blindly for every dataset.

Null geometry or empty coordinates yield blank coordinate cells while properties may still convert. Filter those rows in the sheet if your map import requires every record to have a pin.

Non-point geometries and representative coordinates

LineString, MultiPoint, Polygon, MultiLineString, MultiPolygon, and GeometryCollection cannot be losslessly expressed as two numeric columns. Dumping every vertex would create enormous, irregular rows that break CSV consumers. Instead, the converter picks a representative coordinate — typically an early vertex or a point taken from the first ring — so each feature still appears on a map-like scatter or can be joined approximately by location.

That point is not guaranteed to be a true geometric centroid, pole of inaccessibility, or label point. Long roads may get an endpoint; large polygons may get a vertex on the boundary rather than a visual center. Never compute area-weighted statistics from these proxy coordinates alone.

Keep the original GeoJSON (or a spatial DB) whenever you need length, area, intersections, or cartographic labeling. Use the CSV for attribute analysis and rough “where is this feature roughly located” questions.

The geometry_type column

Every output row includes geometry_type copied from geometry.type. That column lets you filter Points for pin maps, exclude MultiPolygons from a “store locations” chart, or split a mixed layer into separate sheets for different consumers.

Mixed FeatureCollections are common in practice: open-data packages sometimes combine centroids and boundaries. Convert once, then filter on geometry_type in Sheets or the Online CSV Editor rather than asking the converter to drop types silently.

If geometry is null, expect an empty or missing type depending on the feature — treat those rows as attribute-only records and decide whether they belong in your analysis.

Coordinate reference systems and GeoJSON assumptions

RFC 7946 GeoJSON uses WGS84 longitude and latitude in decimal degrees. Most web maps and this converter assume that. If your file uses a projected CRS buried in a nonstandard crs member (older GeoJSON) or was exported from a local grid without reprojecting, the numeric “lat/lon” values will look wrong on a world map.

Reproject to EPSG:4326 in QGIS or ogr2ogr before converting when you know the source is projected. Document the CRS in your README or a metadata cell when sharing CSV with map consumers.

Altitude (a third coordinate element) is uncommon in simple point inventories; if present, the primary lat/lon columns still focus on the horizontal pair. Preserve 3D needs in the original GeoJSON.

Large files, browser limits, and performance

Parsing runs client-side in JavaScript. Tens of thousands of simple Points are often fine; tens of thousands of dense MultiPolygons can stall the tab because the JSON tree and coordinate arrays are large even when you only keep one representative point per feature.

Practical mitigations: filter by bbox or attribute in GIS first; simplify polygons; remove unused property keys; split FeatureCollections by region or category; convert a sample to validate schema, then batch the rest. There is no fixed server quota because nothing is uploaded for the transform — the limit is your device memory and patience.

If the tab freezes, force-quit is safer than waiting indefinitely; reduce the file and retry. For recurring multi-hundred-megabyte national datasets, use a local script (Python geojson / geopandas, Node streaming) instead of a browser paste box.

Excel, Sheets, and after-download cleanup

CSV opens widely, but Excel may auto-convert values that look like dates or large IDs. Format identifier columns as Text when needed. Confirm delimiter handling if your locale expects semicolons — use Text Import with comma selected when everything lands in one column.

Rename cryptic GIS field names (PROP_01) to human labels before sharing. Drop empty property columns that only one feature used. Use geometry_type and a known Point to sanity-check coordinates before building dashboards.

For BI tools, define lat/lon as numeric fields and map them explicitly. Do not double-encode degrees as strings with symbols if the tool expects pure numbers.

Typical workflows

Open data: download city parcels or trees as GeoJSON, convert, analyze attributes in Sheets, keep GeoJSON for the public map.

Retail ops: pull store FeatureCollections from an internal API weekly, convert, archive CSV snapshots for trend charts on status and revenue properties.

Field survey: export points from a collection app, convert, clean attributes, then optionally rebuild cleaned Points with CSV to GeoJSON for republishing.

QA before publish: convert a candidate layer, filter odd geometry_type values, spot-check outliers in lat/lon, fix upstream, re-export GeoJSON for production maps.

Privacy, sensitive locations, and client-side processing

Conversion happens in your browser. The GeoJSON 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 data is often sensitive: home addresses, health facility visits, endangered-species sightings, or employee sites. Even with local conversion, control who receives the CSV, strip precision if policy requires it, and avoid pasting confidential layers on shared machines carelessly.

If policy forbids cloud tools entirely, local conversion still leaves a file on disk — apply the same retention and access rules you would for any spreadsheet of locations.

Reverse path: CSV to GeoJSON

When you need to go back to the map, use the CSV to GeoJSON converter. It builds a FeatureCollection from latitude and longitude columns (plus other columns as properties). That path is ideal for cleaned Point inventories.

Important limitation: flattening polygons to a representative point and then converting CSV back to GeoJSON yields Points, not the original polygons. Rings and topology are not reconstituted from two coordinate columns. Plan your round-trip only when Point geometry is acceptable.

Name your lat/lon columns clearly before the reverse conversion, and keep a backup of the original FeatureCollection whenever boundaries matter.

Quality checklist before you share the CSV

Confirm the input was a FeatureCollection and the row count roughly matches features.length. Confirm property headers are intelligible. Spot-check a known Point’s latitude and longitude on a map. For mixed layers, note which geometry_type values appear.

Open the file in the recipient’s spreadsheet or BI tool. Verify encoding for non-ASCII place names. Record the source URL, export date, and CRS assumption when the extract informs a decision.

Root type was FeatureCollection (or you wrapped a Feature correctly).
geometry_type and lat/lon columns present and plausible.
Sparse property blanks understood as missing keys, not parse errors.
Large-file performance acceptable; sample verified first if needed.
Original GeoJSON retained when polygons or full paths still matter.

Frequently asked questions

Does this support Polygon and LineString geometries, or only Points?

It processes all common geometry types, but for non-Point geometries it extracts a single representative coordinate rather than the full boundary or path. Full geometry data is not representable in flat CSV columns alongside attributes.

What happens if features have different property keys?

The converter scans every feature first to build the complete set of columns, so a feature missing a property gets a blank cell rather than misaligning the row.

Can I convert a single Feature instead of a FeatureCollection?

Wrap it in a FeatureCollection first: { "type": "FeatureCollection", "features": [ yourFeature ] }. The converter expects the FeatureCollection shape.

Is there a column showing the geometry type?

Yes. A geometry_type column is added automatically so you can filter or group by Point, LineString, Polygon, and other types after export.

Is my GeoJSON file uploaded anywhere?

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

How do I go from a spreadsheet back to GeoJSON?

Use the CSV to GeoJSON converter, which builds a FeatureCollection from latitude and longitude columns in your CSV. Note that polygon rings are not restored from a prior flatten — you get Points from lat/lon.

Why is longitude first in GeoJSON but my CSV has latitude and longitude columns?

GeoJSON coordinate arrays are [longitude, latitude]. The CSV exposes labeled latitude and longitude columns so spreadsheet users do not have to remember array order. Always trust the column headers when plotting.

Can I convert TopoJSON directly?

No. TopoJSON is a different encoding. Convert or export to GeoJSON FeatureCollection first (many GIS tools can), then paste the GeoJSON here.

What is a representative coordinate for a polygon?

It is a single point derived from the geometry (such as an early vertex or ring coordinate) so the row has a map-able location. It is not a guaranteed true centroid. Use GIS for accurate centers and area metrics.

Is there a file size limit?

There is no fixed server quota because conversion is client-side, but very large or vertex-heavy files can slow or freeze the browser. Filter or split FeatureCollections before converting when files reach several megabytes or more.

Will feature ids (the id member) become a column?

Properties object keys become attribute columns. If your identifiers live in properties (common practice), they appear as normal headers. Prefer putting stable IDs in properties when you control the export.

Can I use the CSV for spatial joins in a database?

You can load attributes and point coordinates easily. For true spatial joins on polygons or lines, import the original GeoJSON (or a spatial format) into PostGIS or similar — the representative CSV coordinates are not a substitute for full geometries.

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.

GeoJSON to CSV Converter

Output Preview