GeoJSON explained: the format that runs the web map
In GeoJSON, longitude comes first, and that one rule causes a large share of misplaced web-map data. The GeoJSON format is the default for web mapping, so anyone who builds a map meets it sooner or later. This guide explains what it is, how it is put together, where it fits and where it does not.
Key facts
- GeoJSON is defined by RFC 7946 and is always WGS84 (EPSG:4326).
- It stores coordinates longitude first, then latitude (X before Y), the reverse of how people say it.
- In a 10,000-point test the GeoJSON source was 2.69 MB, the baseline the other formats were measured against.
What GeoJSON is
GeoJSON is an open standard for map data written in JSON, which makes it plain text that JavaScript reads natively. That one property is the reason it became the default format of web mapping.
Why the web took to it
Web tools already speak JSON, so GeoJSON drops straight into code without a parser or a plugin. You can read a file by eye, which makes debugging easier, and plain text fits version control, so a map layer can live in a repository next to the code that draws it.
How a file is built
A file holds features, and each feature has two parts: the geometry (Point, LineString or Polygon, plus a multi version of each) and the properties, meaning the data attached to it. A point feature for a cafe, say, holds the coordinates as its geometry and the name as a property. One file can mix as many geometry types as it needs, which is something a shapefile cannot do.
The coordinate rule
The standard, RFC 7946, defines GeoJSON in WGS84, and coordinates are written longitude first, then latitude. That ordering is the reverse of how most people say a position out loud, which is why swapped pairs cause so many misplaced points. A position spoken as latitude 51.5, longitude minus 0.1 appears in the file as minus 0.1 followed by 51.5.
Where it fits, and where it does not
| Situation | Verdict |
|---|---|
| Leaflet, Mapbox GL and OpenLayers maps | Use it: all three read it natively |
| API responses | Use it: web tools already speak JSON |
| Small and medium layers | Use it: simple, readable and universal |
| Very large datasets or streaming | Think twice: a binary format is faster |
| Anything where file size matters most | Think twice: GeoJSON is text, so large files get big |
How to make GeoJSON from what you have
Convert whatever you already hold: KML to GeoJSON, Shapefile to GeoJSON or CSV to GeoJSON. Each one runs in your browser, so nothing is uploaded, and QGIS exports GeoJSON as well. The specification itself lives at geojson.org, and for getting data onto a web map the GeoJSON format remains the easiest route.
“The order right in the RFC surprises people every time: “A position is an array of numbers … longitude, latitude.” Longitude comes first, and that is where half of all misplaced GeoJSON comes from.”
Frequently asked questions
My points are in the wrong place. What should I check first?
Check the coordinate order. GeoJSON writes longitude first, then latitude, and a file written latitude-first puts every point in the wrong spot. Swap the pair and the map usually snaps into place.
A tool expects another coordinate system. What do I do?
Set the coordinate system explicitly when you convert or load the data. RFC 7946 defines GeoJSON as WGS84 only, but some older tools assumed other systems, so stating it removes the guesswork.
Where is the GeoJSON specification?
At geojson.org, which links to RFC 7946, the current standard. The RFC fixes the coordinate system to WGS84 and the coordinate order to longitude first.
When should I not use GeoJSON?
GeoJSON is text, so very large datasets become heavy. For huge layers or streaming, a binary format like FlatGeobuf or a database is faster. GeoJSON suits small to medium layers best.
Why do web maps use GeoJSON?
Web tools already speak JSON, so GeoJSON drops straight into JavaScript. Leaflet, Mapbox GL and OpenLayers read it natively, and it is human-readable, which makes it easy to inspect and version-control.