GeoJSON Validator

Validate GeoJSON against RFC 7946 in your browser

This tool checks a GeoJSON document against the structural rules of RFC 7946, the specification that defines GeoJSON. It catches the mistakes that silently break maps — out-of-range coordinates, unclosed polygon rings, too-few points — and tells you exactly which feature is at fault. It is built for developers wiring up Leaflet, Mapbox, PostGIS, or any spatial database.

Why GeoJSON validation matters

GeoJSON is loosely typed JSON, which means invalid documents can parse without error but fail silently in map renderers or database import tools. The most common real-world problems are:

• Unclosed polygon rings. RFC 7946 requires the last position of a polygon ring to equal the first. Many geometry editors produce these correctly, but hand-edited or generated files sometimes leave the ring open. A Leaflet map or PostGIS ST_GeomFromGeoJSON will silently reject or misrender an unclosed ring.
• Wrong coordinate count. A LineString needs at least two positions; a Polygon ring needs at least four (three corners plus the closing repeat). A single-point line is structurally invalid.
• Out-of-range coordinates. Longitude must be in [−180, 180] and latitude in [−90, 90]. Swapped coordinates — lon/lat entered as lat/lon — frequently produce values like 51.5 for longitude, which is technically in range but places London in Russia. This validator catches the mechanical range violation; the semantic swap you must spot by looking at the center of the bounding box.
• Missing required members. A Feature without a geometry key, or a FeatureCollection without a features array, will cause downstream libraries to throw.

How it works

The tool first parses the text as JSON. It then walks the document by type:

• FeatureCollection must have a features array; each entry is validated as a Feature.
• Feature must carry a geometry and a properties member (object or null).
• Geometry is checked per type — every position needs at least two numbers with longitude in [-180, 180] and latitude in [-90, 90]; LineString needs 2+ positions; each Polygon ring needs 4+ positions and must be closed (first position equals last).

Polygon winding order (exterior counter-clockwise, holes clockwise per the right-hand rule) is reported as a warning, since RFC 7946 requires parsers to accept either order but recommends following it for interoperability.

Reading the error output

Each error identifies the offending element by its position in the document — for a FeatureCollection, the feature index (0-based) and the geometry type. For example:

Feature[2]: Polygon ring[0] is not closed — first and last positions must be equal.
Feature[5]: LineString has only 1 position — minimum is 2.
Feature[7]: position[3] longitude 185.2 out of range [-180, 180].

This lets you jump straight to the problematic feature rather than searching through the whole document.

What is not validated

• Property schema. The tool confirms properties is an object or null as RFC 7946 requires, but does not impose a schema on the property values themselves. Property validation depends on your application.
• Semantic coordinate order. If your generator wrote lat/lon instead of lon/lat, the coordinates may still be numerically in range — the validator checks the structural RFC 7946 rules but cannot detect a semantic swap.
• CRS. RFC 7946 mandates WGS 84 geographic coordinates and deprecates the old crs member. This validator does not check projections.

Everything is computed locally — nothing is uploaded.