GeoJSON Formatter

How the GeoJSON Formatter works, and what it assumes

Formatting and validating are two separate passes over the same document. The first is a strict JSON parse that reports the exact line and column of any syntax error. The second checks the parsed document against RFC 7946, which is where most of the value is: a GeoJSON file can be flawless JSON and still describe nothing a map library can draw.

The structural checks are the ones that catch real bugs. The type must be one of the nine GeoJSON types, spelled exactly — polygon and LINESTRING are both wrong. Coordinates must be nested to the depth the type requires, so a Polygon is an array of rings and not an array of positions. Every position must be two or three numbers. A line string needs two positions, a linear ring needs four, and a ring must end where it began. A Feature must have a geometry member even when its value is null, and a bbox must hold four or six numbers.

Formatting works on the original text of every value rather than converting numbers to JavaScript doubles and back, so a coordinate keeps exactly the digits it was written with. That matters more here than in ordinary JSON: reformatting a file must never move a point, and a naive round trip through a double can change the last decimal place of a longitude.

Using the GeoJSON Formatter

• Finding out why a map library silently draws nothing, which is usually an unclosed ring or a position with the values the wrong way round.
• Making a minified export readable so you can see what is actually in it.
• Minifying a FeatureCollection before putting it in a request body or a configuration value.
• Sorting keys so two versions of the same file produce a diff that shows real changes rather than reordering.

A worked example

This looks like valid GeoJSON and parses as JSON without complaint:

{"type":"Feature","properties":{},"geometry":{"type":"Polygon",
 "coordinates":[[[0,0],[10,0],[10,10],[0,10]]]}}

but the validator reports:

geometry.coordinates[0]
  A linear ring must be closed: the last position has to repeat the first.
  It starts at 0, 0 and ends at 0, 10.

Adding [0,0] to the end of the ring fixes it. This is the single most common reason a polygon is accepted by one library and silently dropped by another: some readers close the ring for you and some refuse it, and nothing in the JSON syntax gives any hint that a rule has been broken.

Where this comes up in GIS work

1. Paste your GeoJSON into the input box, open a .geojson file, or select Load example.
2. Choose Pretty for readable output or Minified for the smallest payload.
3. For pretty output, pick the indentation, and tick Sort keys A–Z if you want a stable ordering for diffs.
4. Select Format GeoJSON, or press Ctrl + Enter (Cmd + Enter on a Mac).
5. Read the structure summary and any problems below, then copy or download the result.

When the output looks wrong

A Feature needs a "geometry" member

Every Feature must have one, even when there is no shape; in that case the value is null rather than the member being left out. A missing geometry member is one of the most common ways a hand-written Feature fails validation in strict readers.

Positions are outside the longitude and latitude range

The file is either in a projected system, which RFC 7946 does not allow, or has latitude and longitude the wrong way round. The formatter warns rather than refusing, because you may well be inspecting a file you did not write.

"type" is not a GeoJSON type

GeoJSON has exactly nine types and they are case-sensitive: Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, GeometryCollection, Feature and FeatureCollection. "polygon" and "LINESTRING" are both invalid.

Valid JSON, but GeoJSON problems are listed below

The two checks are separate. A document can parse perfectly as JSON and still be meaningless as GeoJSON, which is why validating with a plain JSON validator tells you much less than it appears to.

Questions about the GeoJSON Formatter