GeoJSON Tools — Validate & Format Geographic JSON
A validator that knows GeoJSON is not just JSON — it checks the geometry rules that a plain JSON parser will happily accept.
1 tools · Reviewed by Mimamsa, Founder & Engineer, CodeLint.Dev
GeoJSON is defined by RFC 7946, and almost every mistake people make with it produces a document that is perfectly valid JSON and completely invalid GeoJSON. A plain formatter will not catch any of them.
The most common by a wide margin is coordinate order. RFC 7946 specifies longitude first, then latitude — the opposite of how coordinates are spoken, written on maps, and returned by most geocoding APIs. Swap them and your data silently relocates: a point in Berlin lands in the Indian Ocean, and nothing errors until someone looks at a map.
Close behind are unclosed polygon rings (the last position must repeat the first), incorrect winding order for polygons that cross the antimeridian, `bbox` arrays that disagree with the geometry they describe, and feature collections that nest a `FeatureCollection` inside another one. This tool checks the structural rules alongside the JSON syntax, so the errors surface here rather than in your mapping library.
GeoJSON tools
Errors a plain JSON validator will not catch
All of these produce perfectly valid JSON. Only a GeoJSON-aware check finds them:
| Mistake | Symptom | Rule broken |
|---|---|---|
| Latitude and longitude swapped | Data plots in the wrong hemisphere, no error | Position is [longitude, latitude] |
| Polygon ring not closed | Renderer drops or distorts the shape | Last position must equal the first |
| Ring with fewer than 4 positions | Polygon fails to render | A ring needs at least 4 positions |
| <code>properties</code> omitted from a Feature | Strict parsers reject the document | The member is required, even when null |
| Stale <code>bbox</code> | Features clipped out of view | bbox must contain the geometry |
| A <code>crs</code> member present | Ignored, or rejected | Removed in RFC 7946 — WGS 84 is mandatory |
| Nested FeatureCollection | Parsers disagree on how to read it | A FeatureCollection may not contain another |
Frequently asked questions
- Which order do GeoJSON coordinates go in?
- Longitude, then latitude — [x, y] — with an optional third elevation value. This is the reverse of the conventional spoken order and the reverse of what many geocoding APIs return, which makes it the single most common GeoJSON error. Valid longitude runs −180 to 180 and latitude −90 to 90, so any absolute value above 90 in the second slot is a definite mistake.
- Why does my polygon fail validation?
- Almost always an unclosed ring. RFC 7946 requires that the final position in a linear ring be identical to the first, so a four-corner square needs five positions, not four. The other frequent cause is a ring with fewer than four positions, which cannot enclose an area.
- What coordinate reference system does GeoJSON use?
- RFC 7946 mandates WGS 84 (EPSG:4326) with decimal degrees, and removed the CRS member that the older 2008 specification allowed. If your data is in a projected system such as Web Mercator, it must be reprojected before it is valid RFC 7946 GeoJSON.
- How many decimal places should coordinates have?
- Six is right for almost all mapping. At the equator the fifth decimal place is roughly one metre and the sixth about ten centimetres — already finer than consumer GPS accuracy. Exports carrying 14 decimals are mostly noise, and trimming them can cut file size dramatically on large datasets.
- Is my data uploaded?
- No. Validation and formatting run entirely in your browser, which matters because geographic datasets frequently contain addresses, asset locations or other sensitive information.