Invalid GeoJSON geometry won't load
Your GeoJSON fails to parse, renders as a blank map, or your library throws an error about an invalid geometry. The file looks like valid JSON but a mapping tool rejects it.
Why it happens
Valid JSON is not the same as valid GeoJSON. RFC 7946 adds structural rules a plain JSON check never enforces: a Polygon's linear rings must be closed (the last position must equal the first), coordinate arrays must be nested to the depth the geometry type requires, and every position must be [longitude, latitude] in valid ranges. A single unclosed ring, a Polygon nested one level too shallow, or a coordinate out of range is enough to make a conformant reader reject the whole feature.
How to fix it
- Open the geodata validator and upload the file. It checks the structure against RFC 7946 rather than just JSON syntax.
- Read the reported errors: an unclosed ring means the first and last position of a Polygon ring differ — append a copy of the first position to close it.
- Check the nesting depth — a Point is [lng, lat], a LineString is an array of positions, a Polygon is an array of rings (each an array of positions). A common bug is one bracket level too few or too many.
- Confirm coordinate ranges: longitude within ±180, latitude within ±90. Fix any out-of-range positions, then re-validate until the file passes.
Frequently asked questions
My GeoJSON is valid JSON — why is it still invalid?
JSON validity only checks syntax (braces, brackets, commas). GeoJSON validity is the RFC 7946 structure on top of that: closed polygon rings, correct nesting depth per geometry type, and in-range coordinates. A file can be perfect JSON and still break those rules.
What does 'unclosed ring' mean?
A Polygon ring is a closed loop, so RFC 7946 requires its last coordinate position to be identical to its first. If they differ, the ring is 'unclosed'. The fix is to append a copy of the first position to the end of the ring.
Why does my polygon render as nothing?
Common causes are wrong nesting (a Polygon needs an array of rings, not a flat array of positions), an unclosed ring, or coordinates that are swapped or out of range so the shape is placed off the visible map. Validating against the spec pinpoints which one.
Does winding order matter in GeoJSON?
RFC 7946 recommends right-hand-rule winding (exterior rings counter-clockwise, holes clockwise), and most renderers tolerate either. But some strict tools and tile pipelines rely on it, so correcting winding can fix holes that render as filled or polygons that appear inside-out.