What is GeoJSON and what is RFC 7946?

GeoJSON is an open standard for encoding geographic data — points, lines, polygons, and collections of these — as JSON. RFC 7946 is the Internet Engineering Task Force specification that defines the exact rules: valid geometry types, coordinate ordering (longitude first, then latitude), bounding box format, and the structure of Feature and FeatureCollection objects. This tool validates against RFC 7946 specifically.

What errors does the GeoJSON validator catch?

The validator reports invalid geometry type names, malformed coordinate arrays (wrong number of elements, non-numeric values, coordinates outside valid longitude/latitude ranges), missing required fields such as "type" and "coordinates", improperly structured Feature objects (missing or null geometry without explicit null value), and FeatureCollection objects that contain non-Feature members.

Does this tool display a map of my GeoJSON?

No — this tool focuses on validation, linting, and formatting. It does not render a map visualisation. For map previews, tools like geojson.io are useful. This tool is designed for developers who need to confirm correctness and fix errors before the data reaches a mapping library.

Can I use this tool offline?

Yes. Once the page has loaded, all validation and formatting runs in your browser with no network requests. This is particularly useful when working with sensitive location data — customer addresses, asset tracking coordinates, or internal facility maps — that you cannot send to an external server.

Why is my GeoJSON valid JSON but failing GeoJSON validation?

GeoJSON has stricter requirements than plain JSON. A document can be syntactically valid JSON but still violate RFC 7946 — for example, a geometry object missing the "coordinates" field, a polygon ring that is not closed (last coordinate must equal the first), or a type value that is misspelled. The validator checks both JSON syntax and GeoJSON-specific rules.

GeoJSON Validator & Formatter

Validate against RFC 7946, not just JSON syntax. Catches reversed coordinates, unclosed rings and bad bounding boxes — the errors a plain JSON parser accepts happily.

Input

Output

Output will appear here

Longitude comes first

RFC 7946 specifies position arrays as [longitude, latitude] — x before y. This is the reverse of how coordinates are spoken ("fifty-two north, thirteen east"), the reverse of how they are written on maps, and the reverse of what several major geocoding APIs return.

Getting it wrong produces valid JSON, valid GeoJSON structure, and data that is silently in the wrong place. Berlin at [52.52, 13.40] instead of [13.40, 52.52] plots in the Arabian Sea, and nothing errors until a human looks at a map.

One heuristic catches most cases: latitude is bounded at ±90, longitude at ±180. Any second value with an absolute value above 90 is definitely wrong. The reverse is not detectable — both Berlin coordinates are under 90 — so the validator flags the suspicion rather than asserting an error.

The nine GeoJSON types

Type	Structure	Rules that catch people
Point	A single position	None — the simplest case
LineString	Array of ≥2 positions	Two positions minimum; one is not a line
Polygon	Array of linear rings	Each ring needs ≥4 positions and the last must equal the first. The first ring is the exterior; the rest are holes
MultiPoint	Array of positions	—
MultiLineString	Array of LineStrings	—
MultiPolygon	Array of Polygons	Every constituent polygon must independently satisfy the ring rules
GeometryCollection	Array of geometries	Must not contain another GeometryCollection
Feature	A geometry plus properties	`geometry` and `properties` are both required and may both be null
FeatureCollection	Array of Features	Must not nest another FeatureCollection

GeoJSON errors that pass a JSON parser

Polygon ring is not closed

Cause:The last position does not repeat the first. A four-corner square needs five positions, not four — this is the most common polygon error by a distance.

Fix:Append a copy of the first position to the end of every ring, including hole rings.

Feature is missing the properties member

Cause:RFC 7946 requires the key to be present on every Feature. Omitting it is invalid even when there are no properties.

Fix:Add <code>"properties": null</code> or <code>"properties": {}</code>. Both are valid; null signals "no properties", {} signals "an empty set".

bbox does not match the geometry

Cause:A bounding box carried over from an earlier version of the data, or computed before the geometry was edited.

Fix:Recompute it, or remove it — bbox is optional. A stale bbox is worse than none, because tools use it to skip rendering and will clip your data.

A crs member is present

Cause:The 2008 GeoJSON specification allowed a coordinate reference system member. RFC 7946 removed it.

Fix:Delete the member and reproject the data to WGS 84 if it is not already. RFC 7946 mandates WGS 84 with decimal degrees, full stop.

Coordinates have more than three elements

Cause:Extra values appended for time, measure or attributes. RFC 7946 defines position as longitude, latitude and optional altitude, and explicitly forbids more.

Fix:Move the extra values into the Feature’s properties object, where arbitrary data belongs.

Polygon spanning the antimeridian renders as a band across the whole map

Cause:A polygon crossing ±180 longitude, written as if longitude were continuous.

Fix:RFC 7946 requires splitting such geometries at the antimeridian into a MultiPolygon. This is also why the spec prescribes right-hand-rule winding for exterior rings.

Coordinate precision, and why files are ten times larger than necessary

GeoJSON exported from GIS software routinely carries 14 or more decimal places per coordinate. It is worth knowing what those digits represent.

At the equator, one degree of latitude is about 111 km. So the fifth decimal place is roughly 1 metre, the sixth about 10 cm, and the seventh about 1 cm. Beyond the seventh you are describing distances smaller than the GPS receiver's own error, and beyond the ninth you are below the width of an atom.

RFC 7946 explicitly advises against unnecessary precision, and the file-size effect is large: trimming from 14 decimals to 6 removes 8 bytes per number and 16 per position. On a polygon dataset with a million positions that is 16 MB of pure noise — which then has to be transferred, parsed and held in memory by every client.

Six decimal places is the right default for mapping. Use seven if you are doing survey-grade work, and five is plenty for anything displayed at city scale.

About

The GeoJSON Formatter & Validator parses and validates GeoJSON documents according to RFC 7946 — the current authoritative specification for geographic JSON data. It checks for correct geometry type names (Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, GeometryCollection), valid coordinate arrays (correct dimensionality, numeric values, longitude/latitude ordering), properly structured Feature and FeatureCollection objects, and required fields at each level. When errors are found, specific messages describe exactly what is wrong and where. Valid documents are pretty-printed with consistent indentation for easy reading and copying. All processing runs locally in your browser, so you can safely validate location data containing addresses, precise coordinates, or any geospatial information that must not leave your network.

How to use

1 Paste your GeoJSON document into the editor panel on the left.
2 The tool validates it automatically and lists any RFC 7946 violations in the error panel below the editor.
3 Click on an error message to jump to the relevant line in the editor.
4 Fix the highlighted errors — the validator updates live as you type.
5 Once the document is valid, click Copy to copy the pretty-printed output, or use the Format button to apply clean indentation.

What is GeoJSON and what is RFC 7946?: GeoJSON is an open standard for encoding geographic data — points, lines, polygons, and collections of these — as JSON. RFC 7946 is the Internet Engineering Task Force specification that defines the exact rules: valid geometry types, coordinate ordering (longitude first, then latitude), bounding box format, and the structure of Feature and FeatureCollection objects. This tool validates against RFC 7946 specifically.
What errors does the GeoJSON validator catch?: The validator reports invalid geometry type names, malformed coordinate arrays (wrong number of elements, non-numeric values, coordinates outside valid longitude/latitude ranges), missing required fields such as "type" and "coordinates", improperly structured Feature objects (missing or null geometry without explicit null value), and FeatureCollection objects that contain non-Feature members.
Does this tool display a map of my GeoJSON?: No — this tool focuses on validation, linting, and formatting. It does not render a map visualisation. For map previews, tools like geojson.io are useful. This tool is designed for developers who need to confirm correctness and fix errors before the data reaches a mapping library.
Can I use this tool offline?: Yes. Once the page has loaded, all validation and formatting runs in your browser with no network requests. This is particularly useful when working with sensitive location data — customer addresses, asset tracking coordinates, or internal facility maps — that you cannot send to an external server.
Why is my GeoJSON valid JSON but failing GeoJSON validation?: GeoJSON has stricter requirements than plain JSON. A document can be syntactically valid JSON but still violate RFC 7946 — for example, a geometry object missing the "coordinates" field, a polygon ring that is not closed (last coordinate must equal the first), or a type value that is misspelled. The validator checks both JSON syntax and GeoJSON-specific rules.