GeoJSON Validator

RFC 7946 is the IETF standard that defines the GeoJSON format, published in August 2016. It superseded the earlier community GeoJSON specification from 2008. Key changes: coordinates must be in WGS 84 (EPSG:4326), the crs member is deprecated, antimeridian-crossing geometries should be split rather than using coordinates outside [-180, 180], and bbox format is explicitly defined. All modern GIS tools expect RFC 7946 compliance.

GeoJSON polygon rings must explicitly repeat the first coordinate at the end. A triangle requires 4 positions: [[lon1,lat1],[lon2,lat2],[lon3,lat3],[lon1,lat1]]. The first and last must be numerically identical. This is different from some other formats (like Shapefile) that close rings implicitly. PostGIS, QGIS, and Mapbox all reject unclosed rings.

GeoJSON uses [longitude, latitude] order — longitude first. This is the opposite of most human conventions (we say "lat, lon") and many older APIs. If longitude is flagged as out of range [-180, 180], your coordinates are likely swapped. Latitude 51.5 passed as longitude 51.5 is fine, but latitude -0.12 passed as longitude causes no error — swapped London coordinates would silently place data somewhere valid on the globe, making this one of the hardest bugs to spot visually.

No. Winding order (counterclockwise exterior, clockwise holes) is a recommendation in RFC 7946 but not enforced — most tools handle both. Self-intersecting rings, duplicate consecutive vertices, and zero-area polygons are topological issues beyond RFC 7946 structural validation. Use PostGIS ST_IsValid(), QGIS Geometry Checker, or Shapely's is_valid for topological checks.

It's a warning, not an error. The crs member was present in the pre-RFC 7946 GeoJSON spec and is still written by some older tools (particularly QGIS versions before 3.x, and some ESRI exports). RFC 7946 explicitly deprecated it. Modern tools ignore it. To comply with the current spec, remove the crs key entirely — GeoJSON is always assumed to be WGS 84 (EPSG:4326).