Geospatial File Formats: GeoJSON, KML, GPX, CSV, WKT, TopoJSON & Shapefile Explained

A GPS track exported from a fitness watch, a set of delivery stops in a spreadsheet, a shape drawn in a GIS tool, and a query result from a spatial database can all describe the exact same kind of thing — a location, or a path, or an area on a map — while being completely unreadable to each other's software. GeoJSON, KML, GPX, CSV, WKT, TopoJSON, and Shapefile all solve the same underlying problem; they just disagree on how to write it down, and in a few cases, on what they're even capable of representing at all.

What a geospatial file actually is

Underneath the format differences, almost every geospatial file is built from the same three geometry types:

• Point — a single location (a store, a photo, a GPS fix)
• LineString — an ordered path (a route, a hiking track, a road)
• Polygon — an enclosed area (a delivery zone, a property boundary, a lake)

Each geometry is usually paired with properties — arbitrary extra data about it (a name, a timestamp, a category) — though how much property data a format can carry, and how, varies a lot between them.

The coordinate order that trips almost everyone up

Before the formats themselves, one detail causes more real bugs than everything else combined: which number comes first, longitude or latitude. GeoJSON's specification (RFC 7946) fixes it as [longitude, latitude] — X before Y, matching standard math convention. Most other formats and most humans write it the conventional "lat/lon" way instead — latitude first. Mix the two up and you don't get an error; you get a point that's technically valid and geographically wrong, often by thousands of kilometers. A swapped coordinate pair is, by a wide margin, the single most common geospatial data bug — and it's invisible in the raw file, only obvious once the point is actually plotted on a map.

The formats

GeoJSON

A single JSON file — a FeatureCollection, a single Feature, or a bare geometry:

{ "type": "Point", "coordinates": [77.5946, 12.9716] }

Coordinates in [longitude, latitude] order, as above. Supports Point, LineString, Polygon, and their Multi- variants, with arbitrary JSON properties attached to each feature. The native format for most web mapping libraries (Leaflet, Mapbox GL, and similar).

KML

One <Placemark> per feature, XML-based, built for Google Earth:

<Placemark>
  <name>Office</name>
  <Point><coordinates>77.5946,12.9716</coordinates></Point>
</Placemark>

Also [longitude, latitude] order inside <coordinates>. Each Placemark holds one Point, LineString, or Polygon.

GPX

The GPS-device format — waypoints, tracks, and routes:

<wpt lat="12.9716" lon="77.5946">
  <name>Office</name>
</wpt>

Note the order here: lat before lon as separate XML attributes — the opposite convention from GeoJSON and KML's embedded coordinate strings. GPX has no concept of a polygon at all — only waypoints (<wpt>, points), tracks (<trk>, lines), and routes (<rte>, lines). An area simply can't be represented in GPX.

CSV

The simplest and most limited: one row, one point.

name,lat,lon
Office,12.9716,77.5946

A lat/latitude and lon/lng/long/longitude column pair (detected automatically regardless of order) plus any other columns as properties. There's no CSV convention for a line or a polygon — a CSV row is structurally a single point, full stop.

WKT

Well-Known Text — the plain-text geometry format spatial databases like PostGIS produce (via ST_AsText()):

POINT (77.5946 12.9716)

One geometry per line, x y order (longitude then latitude, matching GeoJSON), and no properties at all — just the shape.

TopoJSON

A topology-encoded, quantized variant of GeoJSON, used by D3.js and common in Census/data-journalism datasets. It stores shared borders between adjacent polygons once instead of duplicating them, which is why it's typically far smaller than the equivalent GeoJSON for things like administrative boundaries. Building valid topology back out of arbitrary independent features is a fundamentally harder problem than decoding it — in practice, tooling around TopoJSON is usually one-directional: read and convert from it, not to it.

Shapefile

The classic GIS format: a .zip bundle containing a .shp (geometry), .dbf (attribute table), and usually a .prj (projection). The detail that catches people out: a Shapefile's coordinates are frequently stored in a projected coordinate system — UTM, State Plane, or similar — not plain latitude/longitude at all. The .prj file declares which one; converting a Shapefile correctly means reprojecting those coordinates to WGS84 (ordinary lat/lon) using that declaration, not just relabeling the numbers as if they already were lat/lon.

Format comparison

For a tighter side-by-side of the four most commonly compared formats, see GeoJSON vs KML vs GPX vs Shapefile.

Where conversion fits — and what it can't preserve

Converting a point between any of these formats is close to lossless — it's a coordinate reorder and a file-structure change. Lines and polygons are where real limitations show up: GPX has no polygon concept, so a Polygon feature converting to GPX simply can't go, and a CSV row holds exactly one point, so both LineString and Polygon features are left out converting to CSV. A tool that converts silently and drops those features without telling you is the failure mode to watch for — the count of what didn't survive should always be shown before you download, not discovered afterward when a shape is mysteriously missing.

TopoJSON adds a direction limitation on top of a shape limitation: it can be read and converted from, but not reliably converted to, since reconstructing valid shared-border topology from independent features is a much harder problem than decoding an already-built one.

Where visual verification fits

A coordinate-order bug, a wrong projection, or a technically-valid-but-geographically-nonsensical track all parse without any error — nothing about a well-formed GeoJSON or GPX file distinguishes "correct" from "off by one continent." The only real check is plotting it on an actual map and looking: a point in the ocean where a city should be, or a track that jumps impossibly, is obvious at a glance and invisible in the raw coordinates. See how to spot common geospatial data errors before you trust a dataset for the specific failure modes to check for.

Where each step happens

• Converting between formats — the Geo Format Converter handles GeoJSON, KML, GPX, CSV, WKT, TopoJSON, and Shapefile, reprojecting Shapefiles to WGS84 automatically and showing exactly how many features (if any) can't survive the target format.
• Seeing exactly what a conversion changed — the Geo Conversion Loss Inspector converts for real and diffs the output against the source, and Geo Dataset Compare runs the same kind of diff between any two files, not just a conversion pair — see how to verify a geospatial conversion actually worked.
• Viewing and verifying visually — the GeoJSON / KML / GPX / CSV Viewer renders a file directly on a map so a coordinate-order bug or a bad export is visible immediately, and doubles as a distance/area measuring tool with no file needed at all.
• Checking CRS and geometry deterministically — the Geo QA & CRS Inspector reads a Shapefile's .prj, flags coordinates left in the wrong projection, and checks structural geometry (unclosed rings, wrong winding order, antimeridian crossings) across GeoJSON, KML, GPX, and the rest — worth running before or instead of a visual check.
• Fixing a bad projection or invalid geometry — the Geo Reprojection & Repair Workbench reprojects a file left in the wrong CRS to WGS84 (pick a UTM zone, or paste a CRS definition) and automatically closes unclosed rings and fixes wrong winding order — see how to reproject a Shapefile without a desktop GIS.
• Cleaning up a GPX track — the GPX Cleaner checks a track for duplicate points, backward timestamps, and implausible speed jumps, and removes exact duplicates automatically — see how to clean up a GPX track before trusting it.
• Extracting location from photos — the EXIF GPS Extractor pulls GPS coordinates straight out of a photo's embedded metadata and exports them as GeoJSON, CSV, or KML — a common starting point when the "geospatial data" you have is really just a folder of geotagged pictures.