GeorafGeoraf Team
·5 min read·

What Is GeoJSON? A Plain-English Guide for Non-GIS People

GeoJSON is JSON for maps. A practical explainer for people who keep seeing the word and want a real answer, not a Wikipedia paragraph.

A GeoJSON file structure illustrated, showing the FeatureCollection, features, geometry, and properties hierarchy.

You keep seeing the word "GeoJSON." A library you're using mentions it. A colleague sends you one. A map you tried to embed asks for one. You'd like a real answer to what it actually is, ideally without reading a Wikipedia article that assumes you already know what a spatial reference system is.

Here's the real answer: GeoJSON is JSON for maps. It's a way of writing down "this point is at this longitude and latitude, and here's some data attached to it" in a format any programming language already knows how to read.

That sentence is technically the whole story. The rest of this piece is the details that actually matter when you have to work with one.

A GeoJSON file, in 20 seconds

Here's what one looks like:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [13.4050, 52.5200]
      },
      "properties": {
        "name": "Brandenburg Gate",
        "city": "Berlin"
      }
    }
  ]
}

That's it. One entry, with a location (the coordinates) and some properties (the name and city). Open it in any text editor, send it through any JSON parser, save it as .geojson or .json and you have something every modern map library can read.

If you've worked with regular JSON before, this is exactly that, plus one rule: the geometry field describes a thing on a map.

What the geometry can be

There are seven kinds of geometry in GeoJSON, but you'll mostly see four:

  • Point: a single location. One pair of coordinates.
  • LineString: a line. An array of points.
  • Polygon: a closed outline. An array of points where the first and last coordinates match.
  • MultiPolygon: several outlines belonging to the same entry, like a country with islands.

The others (MultiPoint, MultiLineString, GeometryCollection) exist but you'll see them rarely outside of dense datasets.

The format always lists coordinates as [longitude, latitude], in that order. This trips up roughly 100% of people the first time they encounter it. Most humans say "lat-long" out loud. GeoJSON does it the other way around because that's the standard math convention (x then y). When in doubt: longitude is the east-west number, latitude is the north-south one. Berlin is around 13 longitude, 52 latitude.

Why GeoJSON beat the other formats

Twenty years ago, geographic data lived in proprietary or XML-based formats: Shapefile, KML, GML, MapInfo TAB. Each one needed special libraries to parse and special tools to view.

Then the web happened. JSON became the universal data interchange format because it's text, it's simple, and every programming language can read it. GeoJSON is just JSON with a small geometry spec on top. It won because:

  • It works in JavaScript out of the box (no library required to parse it).
  • It works in Python, Ruby, Go, Rust, Java, whatever, with a one-liner.
  • You can read it in a text editor. The Shapefile spec contains the phrase "binary format" forty-three times.
  • It plays nicely with REST APIs. Every modern map service can accept or return GeoJSON over HTTP.

The trade-off is that GeoJSON does not carry styling. It doesn't know what color you want the lines to be, or what icon to use for the points. Styling is the responsibility of whatever library is rendering the file. For some workflows that's a feature (separation of concerns), for others it's a pain (you have to maintain styling separately).

When to use it, and when not to

Use GeoJSON when:

  • You're building anything web-based that displays a map (Leaflet, Mapbox, MapLibre, Google Maps, OpenLayers all read it natively).
  • You're moving data between tools and you want a format that everyone speaks.
  • You're sending geographic data over an API.
  • You're storing data in a database that handles JSON well (Postgres with PostGIS, MongoDB, etc.).

Don't use GeoJSON when:

  • Your dataset is enormous, hundreds of MB or more. GeoJSON's verbosity becomes a problem at scale. Look at GeoParquet, FlatGeobuf, or vector tiles instead.
  • You need styling baked into the file itself. Use KML or KMZ.
  • You're working in a desktop GIS workflow with legacy tools that expect Shapefile. (Even then, you can usually convert.)
  • You need 3D geometry, raster data, or anything beyond simple vector outlines.

How it relates to other formats you've heard of

If you have a file in one of these and want it as GeoJSON:

You haveEasy path
Shapefile (.shp + siblings)Convert (we have a guide). Almost always lossless.
KML or KMZConvert (also covered). Styling gets dropped.
CSV with lat/long columnsMap the columns to geometry.coordinates. Most tools do this automatically.
Excel with lat/long columnsSame as CSV. Export to CSV first.
A database with geometry columnsMost databases (PostGIS, SpatiaLite, MongoDB, Supabase) have a ST_AsGeoJSON() or toGeoJSON() function.

If you just need to do the conversion once, drop it on Georaf. The converter handles all five of those inputs and gives you valid GeoJSON out the other side, with a quality check so you know if anything's broken in the data itself.

The edge cases that actually matter

Coordinate order: as mentioned, GeoJSON is [longitude, latitude]. If your map shows everything in the wrong country, this is the first thing to check.

Coordinate systems: officially, GeoJSON is supposed to be in WGS 84 (the GPS coordinate system) and only WGS 84. Some older files cheated and stored projected coordinates anyway, which causes problems with strict parsers. See our coordinate-systems explainer if your data is suspiciously off-map.

Polygon winding order: outlines should be drawn counter-clockwise (the official spec calls this "right-hand rule"). Most tools don't care, but some strict ones (notably Mapbox GL JS in certain modes) will refuse to render polygons in the wrong winding order. If your shapes appear inverted, this is why.

Property type weirdness: properties can be strings, numbers, booleans, or null. They can technically be nested objects and arrays too, but doing that is asking for trouble, most tools assume flat properties.

File size: a GeoJSON of even moderately detailed boundaries can be huge. A country dataset with millimeter-precise outlines might balloon to 50 MB. Simplify the geometry, or use a tile-based format, before you ship something that size to the browser.

A quick mental model

If JSON is "structured data as text," GeoJSON is "structured map data as text." Same idea, same syntax, just with a rule that one field is the location.

Once you've seen one, you've seen the format. Spend two minutes opening a sample file in a text editor and the spec stops feeling abstract.

If you have a file in some other format and want it as GeoJSON, Georaf converts it in one click, with a quality check on the way through.