GeoJSON Viewer: Draw and Check Any GeoJSON

Heading to the field? Install this site from your browser menu and this tool works with no signal. See how

How to use this tool

Drop a .geojson or .json file on the panel above, or press Choose a file. Everything is drawn on the map and listed in the table below, with lengths and areas worked out. Nothing is uploaded, which matters more than usual here, because GeoJSON is the format people paste straight out of an API response without thinking about what is in it.

If the file will not load, the message says why in plain language rather than showing a stack trace. The two failures worth knowing about are covered further down.

GeoJSON arrives in four different shapes

People say GeoJSON as though it names one structure. The specification allows several, and all of them are valid.

A FeatureCollection is the usual export from any GIS: a list of features, each with a geometry and a properties object. A single Feature on its own is what an API returns when you ask for one record. A bare geometry, just a Point or a Polygon and its coordinates with no wrapper at all, is what a database column typically holds. And a plain array of features, with no wrapper, is what scripts produce.

This tool accepts all four and normalises them to a FeatureCollection on the way in. That is worth stating because refusing a bare geometry for lacking a wrapper is the most common complaint about GeoJSON tools, and it is a refusal with no justification in the specification.

Two rules that are easy to break and hard to see

GeoJSON is always WGS84 longitude and latitude. There is no projection field. Older versions of the specification allowed a crs member, and RFC 7946 deprecated it, so a file carrying grid metres is not GeoJSON in a projected system, it is simply wrong. If your features land in the sea off west Africa, this is why.

Positions are written longitude first, then latitude. That trips people constantly, because it is the reverse of how everyone speaks and the reverse of what a GPS screen shows. The first number in every coordinate pair is the one that runs east to west.

Ring winding is the second rule. An outer ring should run counter clockwise and a hole should run clockwise. Plenty of software ignores this and still draws correctly, so files with the wrong winding circulate freely, right up until they reach something that uses the winding to decide what is solid, at which point a lake becomes an island.

A worked check you can repeat on paper

Load the sample and check the bounding box yourself. It is the fastest way to confirm you have the coordinate order the right way round, and it takes ten seconds.

The sample holds three points: minus 109.05 and 37.0, minus 108.60 and 37.25, and minus 108.20 and 37.05.

• Take the first number in each pair, the longitudes: minus 109.05, minus 108.60, minus 108.20. The smallest is minus 109.05 and the largest is minus 108.20.
• Take the second number in each pair, the latitudes: 37.0, 37.25, 37.05. The smallest is 37.0 and the largest is 37.25.
• So the bounding box, written as GeoJSON writes it, is minus 109.05, 37.0, minus 108.20, 37.25.

That is exactly what the status line above reports. Now notice what the check actually proved: the longitudes are all around minus 109, which is a plausible longitude and an impossible latitude, since latitude stops at 90. If your numbers came back the other way round, the file has the pairs reversed and every feature is in the wrong place.

It is a crude test and it catches the single most common fault in hand assembled GeoJSON.

When a file will not load

Two messages account for almost everything. Invalid JSON means the text is not parseable at all, and the usual cause is a trailing comma after the last item in a list, which JavaScript tolerates and JSON does not.

The other says the JSON is not GeoJSON. The most frequent reason is TopoJSON, which looks similar, is a different format, and stores geometry as shared arcs rather than as coordinates. This tool refuses it by name rather than half reading it, because a partial read of TopoJSON produces plausible looking nonsense.

Mistakes that catch people out

Assuming a validator that says valid means the file will draw correctly. Validity is about structure. A perfectly valid file can have the coordinate pairs reversed, the rings wound backwards, or grid metres where degrees belong.

Pasting coordinates from a spreadsheet in latitude then longitude order. This is the big one, and the bounding box check above catches it in seconds.

Expecting a crs member to be honoured. It is deprecated, most software ignores it, and relying on it means your file behaves differently depending on who opens it.

Sending enormous GeoJSON by email. It is verbose text and compresses extremely well. Zip it, or convert it to a format built for transport.

Losing nested properties. GeoJSON allows properties to hold objects and arrays. A shapefile attribute table cannot, so anything nested is flattened to text on the way out. This tool shows them as text so you can see what will survive.

Related Calculators and Reference

GeoJSON is usually a stopping point between two other formats rather than a destination.

• KML and KMZ Viewer for the same job on a Google Earth file, with folder paths and attributes.
• Shapefile Viewer for reading a shapefile the same way, without installing GIS software.
• WKT Viewer for the database flavour of the same geometry, one line per shape.
• KML to Shapefile Converter for taking data on into GIS as a shapefile once you know what is in it.
• CSV Cleaner for XYZ data for cleaning the feature table this tool exports.
• The RFC 7946, the GeoJSON specification is the authority on the coordinate order and ring winding rules described above.