TSV to GeoJSON
A table with coordinate columns becomes a GeoJSON FeatureCollection of points, ready to drop into Leaflet, Mapbox, QGIS, or a GitHub gist (which renders GeoJSON as a map automatically). Column names like lat/lon, latitude/longitude, and y/x are recognised without configuration; everything else in the row is carried through as feature properties.
How to use
- Paste or drop the TSV. If the coordinate columns have recognisable names, features appear immediately.
- Otherwise name them in the latitude and longitude fields — by header name or 1-indexed position.
- Read the status line. It reports the feature count, rows skipped for unusable coordinates, and — importantly — whether any coordinate fell outside the valid range.
- Download as
.geojsonand open it in geojson.io or QGIS to check the points land where you expect.
Coordinate order: the mistake everyone makes once
GeoJSON stores coordinates as [longitude, latitude] — x before y, the opposite of how people say and write them. This tool handles that for you: you name the lat and lon columns and it emits them in the correct order. But it's worth knowing, because the symptom of getting it wrong elsewhere is unmistakable and easy to misread: your European points end up in Somalia, or your US points in Antarctica.
The status line warns when a latitude is outside ±90 or a longitude outside ±180, which is the reliable signal that the columns are swapped — a latitude of 121 cannot exist. Values inside both ranges can still be swapped without detection, so if all your points land in a plausible-but-wrong place, try switching the two column names.
Properties and precision
Every column that isn't a coordinate becomes a property on the feature. With type properties on, numeric-looking values become JSON numbers and true/false become booleans, which matters for styling rules and filters in mapping libraries — population > 1000000 only works if population is a number. The usual coercion caveat applies: an ID column of digits becomes a number and loses any leading zeros.
Six decimal places of latitude is about 10 cm at the equator, which is more than enough for anything short of surveying and is the sensible default. Trimming to 5 or 4 decimals meaningfully shrinks a large file — coordinates dominate the byte count of a point dataset — and 4 decimals is still roughly 11 metres.
Assumed CRS is WGS 84 (EPSG:4326), which is what the GeoJSON specification mandates. If your coordinates are in a projected system — UTM metres, British National Grid, Web Mercator — they need reprojecting first, and a value like 531000 in a latitude column is the sign that's the case.
FAQ
Can it make lines or polygons?
No — points only. Building a LineString means knowing the order of points and where one line ends, which a flat table doesn't express. For line and polygon work, geojsonkit.org has viewing, validation, and conversion tools.
What about degrees, minutes, seconds?
Not parsed — a value like 52°31'12"N is skipped as unusable. Convert to decimal degrees first; the arithmetic is deg + min/60 + sec/3600, negated for S and W.
Why were some rows skipped?
Their coordinate cells were empty or not numeric. That's usually a geocoding step that failed for those rows. Filter rows on the empty coordinate to pull them out and see what they have in common.
Is there a feature limit?
Not imposed, but pretty-printed GeoJSON is verbose — 100,000 points is tens of megabytes. Turn pretty-printing off for large sets, and consider whether the consumer would be happier with the TSV.
Privacy
100% client-side. No upload — location data in particular never leaves your machine. See the privacy policy.