Validating...
Paste a GeoJSON object above and click Validate / Format, or choose a Quick Load preset.
Checks geometry types, ring closure, coordinate bounds, and RFC 7946 compliance.
What Is GeoJSON? A Web Mapping Format Overview
GeoJSON is an open standard for encoding geographic data structures using JSON. It defines nine geometry types — Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, GeometryCollection, Feature, and FeatureCollection — each with a precise structure that mapping libraries like Leaflet, Mapbox GL JS, and OpenLayers consume directly. A single typo or structural deviation causes silent failures: a polygon with an unclosed ring simply disappears from the map without any browser console error.
Common GeoJSON Validation Errors and How to Fix Them
The most frequent source of broken GeoJSON in production is the unclosed ring. The GeoJSON specification (RFC 7946, Section 3.1.6) requires that the first and last positions in every linear ring be identical. A polygon created by clicking points in a web editor will often close automatically, but JSON exported from a database or generated programmatically may not. This validator checks ring closure to 10 decimal places and reports the exact coordinates that do not match.
The second most common issue is invalid coordinate order. RFC 7946 mandates longitude first, then latitude — the opposite of the traditional lat/lon order used in GPS and most geographic databases. If your map shows features in the ocean when they should be on land, reversed coordinates are the likely cause. This tool validates that all longitude values fall within [−180, 180] and latitude values within [−90, 90], catching the most egregious reversals.
Clockwise polygon winding order is a warning rather than an error. RFC 7946 specifies that exterior rings should be wound counter-clockwise (positive shoelace area), but many GIS tools output clockwise rings. Leaflet and Mapbox typically render both correctly, but Turf.js boolean operations and some server-side spatial databases may produce incorrect results with CW-wound polygons. Fix it by reversing the coordinate array.
GeoJSON Geometry Types Explained
Every GeoJSON object must have a "type" field. The nine valid types fall into three categories: geometry primitives (Point through MultiPolygon), the GeometryCollection container, and the Feature wrappers that add properties to geometries.
| Type | coordinates Structure | Minimum |
|---|---|---|
| Point | [lon, lat] | 1 position |
| LineString | [[lon,lat], ...] | 2 positions |
| Polygon | [[[lon,lat], ...]] | 4 per ring (closed) |
| MultiPoint | [[lon,lat], ...] | 1 position |
| MultiLineString | [[[lon,lat], ...], ...] | 2 per line |
| MultiPolygon | [[[[lon,lat], ...]], ...] | 4 per ring |
| GeometryCollection | "geometries": [...] | empty array OK |
| Feature | "geometry" + "properties" | both can be null |
| FeatureCollection | "features": [...] | empty array OK |
How to Format and Minify GeoJSON for Production
Raw GeoJSON exported from QGIS or PostGIS is often already minified — no whitespace, everything on a single line. This is ideal for HTTP responses and file transfers because it minimises payload size. A typical 100-feature polygon FeatureCollection might be 800 KB formatted and 600 KB minified — a 25% saving that matters at scale.
During development, formatted (pretty-printed) GeoJSON is far easier to read and diff in version control. This tool's Format action re-indents the entire JSON with 2-space indentation using Go's json.MarshalIndent, which also normalises key ordering. The output size is shown so you can immediately see the trade-off before copying the result into your codebase.
Coordinate Order and CRS in GeoJSON (RFC 7946)
The biggest source of confusion in GeoJSON is coordinate order. RFC 7946 defines GeoJSON as always using the WGS84 geographic coordinate reference system (EPSG:4326) with coordinates in longitude, latitude order. This is the opposite of the ISO 6709 standard used by GPS devices and most databases, which store latitude first.
Before RFC 7946, the older GeoJSON specification (2008) allowed a "crs" member to specify an alternative coordinate reference system. RFC 7946 explicitly removed this feature — all GeoJSON is now implicitly WGS84. If your GeoJSON still contains a "crs" member, this validator raises a DEPRECATED_CRS warning. Remove the field before publishing the data.
Validation Error Code Reference
| Code | Level | Triggered When |
|---|---|---|
| INVALID_JSON | error | Input cannot be parsed as JSON |
| MISSING_TYPE | error | Root object has no "type" field |
| INVALID_TYPE | error | "type" value is not one of the 9 valid GeoJSON types |
| MISSING_COORDINATES | error | Geometry type requires "coordinates" but it is absent |
| INVALID_COORD_ARRAY | error | "coordinates" has wrong nesting depth or non-numeric values |
| COORD_LON_OUT_OF_RANGE | error | Longitude outside [−180, 180] |
| COORD_LAT_OUT_OF_RANGE | error | Latitude outside [−90, 90] |
| UNCLOSED_RING | error | Polygon ring first ≠ last position |
| RING_TOO_SHORT | error | Polygon ring has fewer than 4 positions |
| POLYGON_CW_WINDING | warning | Outer ring wound clockwise (RFC 7946 requires CCW) |
| DEPRECATED_CRS | warning | Root object contains a "crs" member |
| INVALID_BBOX | error | "bbox" array is malformed or min > max |
Frequently Asked Questions
Why does my GeoJSON polygon fail validation?
The most common cause is an unclosed ring (UNCLOSED_RING). The GeoJSON spec requires the first and last positions of every ring to be identical. To fix it, duplicate the first coordinate and append it to the end of the ring array. The second common cause is too few positions (RING_TOO_SHORT) — a valid ring needs at least 4 positions (3 unique vertices plus the repeated closing position).
What is RFC 7946 and why does it deprecate the CRS member?
RFC 7946, published by the IETF in 2016, is the definitive GeoJSON specification. It replaced the original 2008 GeoJSON format specification. The earlier spec allowed a "crs" member to declare any coordinate reference system, but this caused interoperability problems — consuming applications could not safely assume the coordinate order or units. RFC 7946 resolved this by mandating WGS84 (EPSG:4326) with longitude/latitude order for all GeoJSON, making the "crs" member unnecessary and confusing.
Does GeoJSON use longitude first or latitude first?
GeoJSON uses longitude first, then latitude — written as [lon, lat]. This follows the x/y (easting/northing) convention used in Cartesian coordinate systems. It is the opposite of the lat, lon order used by Google Maps, GPS devices, and the ISO 6709 standard. If your features appear in the wrong location, reversing the coordinate values (e.g. changing [40.7128, -74.006] to [-74.006, 40.7128]) usually fixes the problem.
How do I fix an unclosed ring error in GeoJSON?
Find the ring that fails validation using the path shown in the error (e.g. (root).coordinates[0]). Copy the first position in that ring array and paste it as the last element. For example, if your ring is [[0,0],[1,0],[1,1],[0,1]], add the first point: [[0,0],[1,0],[1,1],[0,1],[0,0]]. In code, this is simply: ring.push(ring[0]).
What is the difference between GeoJSON format and minify?
Formatting (pretty-printing) adds consistent 2-space indentation so the JSON is readable by humans. Minifying removes all whitespace to produce the smallest possible file. Both operations produce semantically identical GeoJSON — only the whitespace changes. Use formatted output during development for readability and version control diffs; use minified output in production APIs and static file servers to reduce transfer size.
Can GeoJSON store 3D coordinates?
Yes. RFC 7946 allows an optional third element in each position for altitude: [lon, lat, alt]. The altitude is in metres above the WGS84 ellipsoid. This validator accepts 2- or 3-element positions as valid. However, most web mapping libraries (Leaflet, Mapbox GL JS) ignore the altitude value entirely — 3D rendering requires specialised tools like CesiumJS or deck.gl.
Related GIS Tools
Shapefile to GeoJSON Converter
Export shapefiles as GeoJSON — then validate the output here
KML to GeoJSON Converter
Convert Google Earth KML files to GeoJSON
EPSG Code Lookup
Find projection definitions and CRS details by EPSG code
UTM Zone Finder
Get UTM zone, EPSG code, and Proj4 string from lat/lon
WGS84 to UTM Converter
Project WGS84 decimal degrees into UTM eastings/northings
Coordinate Converter
Convert between decimal degrees, DMS, and MGRS formats