About

GeoJSON (RFC 7946) is the standard interchange format for geographic features. Most spatial datasets, however, originate as CSV exports from GPS loggers, survey tools, or municipal databases. A malformed conversion - swapped lat/lon axes, truncated coordinates, or invalid property encoding - will silently corrupt every downstream analysis: misplaced markers, broken spatial joins, and failed API ingestion. This tool parses CSV files following RFC 4180 rules (quoted fields, embedded delimiters, multiline values), auto-detects coordinate columns by header heuristics, validates that lat falls within [−90, 90] and lon within [−180, 180], and outputs a spec-compliant FeatureCollection. Rows with unparseable or out-of-range coordinates are flagged individually rather than silently dropped.

The converter supports four common delimiters (comma, semicolon, tab, pipe) with automatic detection, optional elevation mapping to a 3D coordinate array, and full control over which CSV columns appear as GeoJSON feature properties. Output conforms to the WGS 84 coordinate reference system (EPSG:4326) as mandated by RFC 7946. Note: this tool assumes planar point geometries. LineString or Polygon construction from ordered point sequences requires topology inference not performed here.

Formulas

Each CSV row is converted to a GeoJSON Feature with the following structure per RFC 7946:

Feature(row) → { "type": "Feature", "geometry": { "type": "Point", "coordinates": [lon, lat] }, "properties": { … } }

Where lon = longitude value from the mapped column, constrained to −180 ≤ lon ≤ 180, and lat = latitude value, constrained to −90 ≤ lat ≤ 90. When elevation is mapped, coordinates become a 3D array: [lon, lat, alt].

Delimiter auto-detection counts candidate characters in the first 5 lines (outside quoted regions) and selects the character with the most consistent per-line frequency:

score(d) = count(d)stddev(counts per line) + 1

The delimiter with the highest score is selected. Ties favor comma > semicolon > tab > pipe.

The optional bounding box is computed as:

"bbox": [min(lon), min(lat), max(lon), max(lat)]

Reference Data

GeoJSON Type	Geometry	Typical Source	Coordinates Format
Point	Single location	GPS waypoints, addresses	[lon, lat] or [lon, lat, alt]
MultiPoint	Grouped locations	Sensor clusters	[[lon, lat], …]
LineString	Connected path	Routes, tracks	[[lon, lat], …]
Polygon	Enclosed area	Parcels, boundaries	[[[lon, lat], …]]
FeatureCollection	Array of features	Any dataset	N/A (container)

Common Header Name	Maps To	Valid Range	Notes
lat, latitude, y, lat_dd	Latitude	−90 to 90	Decimal degrees, WGS 84
lon, lng, longitude, x, lon_dd, long	Longitude	−180 to 180	Decimal degrees, WGS 84
alt, altitude, elevation, elev, z	Elevation	Any number	Meters above WGS 84 ellipsoid
name, title, label, id	Property	Any string	Preserved as feature property

Delimiter	Character	Common Usage	Auto-Detect Pattern
Comma	,	Standard CSV (RFC 4180)	Highest frequency outside quotes
Semicolon	;	European locale CSVs	Used when comma is decimal separator
Tab	\t	TSV exports, database dumps	Uniform tab count per line
Pipe	\|	Legacy systems, mainframes	Rare in natural text

RFC 7946 Rule	Requirement	This Tool
Coordinate Order	[longitude, latitude]	Enforced - CSV lat/lon swapped to GeoJSON order
CRS	WGS 84 (no CRS member)	Compliant - no CRS property emitted
Antimeridian	Split geometries at ±180°	Points only - no splitting needed
Bounding Box	Optional [w, s, e, n]	Computed from all valid features
Right-Hand Rule	Polygon winding order	N/A (Point geometry only)
Precision	6 decimal places ≈ 0.11 m	Preserves source precision, max 8 decimals

Frequently Asked Questions

RFC 7946 mandates [longitude, latitude] to align with the mathematical convention of [x, y] on a Cartesian plane, where longitude represents the east-west axis (x) and latitude the north-south axis (y). This is the opposite of the common GPS convention. This converter automatically swaps the axes from your CSV mapping, so you select the column labeled "latitude" and the column labeled "longitude" and the output will be correctly ordered.

Rows where the latitude or longitude cell is empty, non-numeric, or outside the valid range (latitude: −90 to 90, longitude: −180 to 180) are excluded from the FeatureCollection and counted as skipped rows. The conversion summary displays the exact count and row numbers of skipped entries so you can fix the source data.

The parser implements RFC 4180 fully: fields enclosed in double quotes can contain commas, newlines, and literal double-quote characters (escaped as two consecutive double quotes ""). This means a CSV exported from Excel with address fields like ""123 Main St, Suite 4"" will parse correctly as a single field value.

Yes. Map a CSV column to the Elevation field in the column mapping interface. When set, each Feature's coordinates array becomes a 3-element array [longitude, latitude, altitude] per RFC 7946 Section 3.1.1. The altitude value is interpreted as meters above the WGS 84 reference ellipsoid. If elevation data is missing for a specific row, a 2D coordinate is emitted for that feature.

No. RFC 7946 removes the optional CRS member that existed in the older GeoJSON 2008 specification. All compliant GeoJSON uses WGS 84 (EPSG:4326). If your CSV contains coordinates in a projected CRS (e.g., UTM, State Plane), you must reproject them to WGS 84 decimal degrees before using this converter. Feeding projected coordinates will produce geometrically valid but geographically incorrect GeoJSON.

The tool processes files entirely in your browser with no server upload. Practical limits depend on available RAM. Files under 10 MB (roughly 100,000 rows) convert in seconds. Files between 10-50 MB use a Web Worker to prevent UI freezing. Beyond 50 MB, browser tab memory limits may apply. For very large datasets, consider splitting the CSV and merging the output FeatureCollections.