geojsonkit.org
GeoJSON utilities, in the browser
Say hi →

GeoJSON Validator

Paste GeoJSON, get a line-accurate spec report. Checks JSON syntax, required fields per RFC 7946, geometry types, coordinate shape, longitude/latitude ranges, and polygon ring closure. 100% in-browser.

GeoJSON Validator

updated 8 June 2026

Drop a .geojson / .json file, or

What this tool does

It takes a chunk of GeoJSON and hands back a list of everything in it that breaks RFC 7946 — the modern GeoJSON spec. It walks the structure recursively and reports each problem as a path: message line, so you know exactly which feature, geometry, or coordinate is at fault. There are no options to set: paste, click Validate, read the report.

The intent it closes: "my GeoJSON loads in one library but breaks in another, and I need to know what's actually wrong with it." This is a structural / syntax validator — it checks that the shape matches the spec. It does not check your schema (which properties you expect), and it won't second-guess your data semantically. If you only need readable formatting, the Formatter is the lighter tool.

How this tool works

One click runs a three-stage pass, entirely in your browser. Nothing is uploaded; your input is also saved to the session so it follows you when you open another tool on the site.

1. Parse the JSON

First the text goes through JSON.parse. If that fails — a trailing comma, an unclosed bracket, a smart quote — the run stops here, the status bar shows Invalid JSON., and the report pane gives you the parser message with a (line N, col N) position so you can jump straight to it. A clean parse is the only gate to the structural checks.

2. Walk the structure

The parsed object is checked against the spec from the top down. Every object must carry a type string. A FeatureCollection must have a features array, and each feature is validated recursively. A Feature must have a geometry member (an object, or explicitly null) and a properties member. A geometry's type must be one of Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, or GeometryCollection — anything else is flagged as unknown. A GeometryCollection must hold a geometries array, each member of which is validated in turn.

3. Check the coordinates

For each geometry the coordinate arrays are inspected down to the position level. A position must be an array of at least two finite numbers — [lng, lat], with an optional third elevation value — and longitude must fall in [-180, 180], latitude in [-90, 90]. LineString and MultiLineString lines need at least two positions; Polygon rings need at least four positions and must be closed (the first position must equal the last). Each failure is collected, not just the first.

4. Read the report

If nothing is wrong, the status bar turns green with Valid GeoJSON. and the report reads OK — no structural issues. followed by the feature count and the top-level type. If there are problems, the status shows Invalid — N issue(s). and the pane lists every issue as path: message, for example $.features[0].geometry.coordinates[0]: Longitude out of range [-180,180]: 181. Copy report drops the whole list onto your clipboard for a bug tracker or a colleague.

Example

Input (a simple Point feature):

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [102.0, 0.5]
  },
  "properties": { "prop0": "value0" }
}

Output (the report pane):

OK — no structural issues.
Features: 1
Type: Feature

Swap the coordinates to [0.5, 200.0] and the report turns into a single issue line — $.geometry.coordinates: Latitude out of range [-90,90]: 200 — because 200 can't be a latitude.

Tips & common pitfalls

  • Longitude comes first. This is the #1 GeoJSON mistake. It is always [longitude, latitude], never the other way around. If your points are landing in the wrong place, paste the same data into the GeoJSON Viewer to see it on a map.
  • Polygons must be closed. The first coordinate pair in a Polygon ring must be exactly identical to the last one, or you get a "ring must be closed" issue.
  • At least four points for a ring. A valid Polygon ring needs four positions (the fourth being the closure of a triangle). Three positions isn't a closed shape.
  • It checks structure, not schema. This tool confirms the GeoJSON shape is legal. It does not verify that you have the properties your app expects, and it does not check winding order — most renderers tolerate "wrong" winding, so it isn't flagged here.

Troubleshooting

I get "Invalid JSON." with a line and column immediately.

The input isn't valid JSON at all, so the structural checks never run. Jump to the (line N, col N) position in the report and look for trailing commas, unquoted keys, or smart quotes (common if you copied from a Word doc). If you're pasting a URL, this tool won't fetch it — paste the actual file content.

The report says my coordinates are out of range.

Check your order. Longitude must be between -180 and 180, latitude between -90 and 90. [120, 45] is fine; [45, 120] tries to put a point 30 degrees past the North Pole.

Every position in one geometry is flagged.

A single misplaced bracket can shift the whole array a level. The path on each issue line (like coordinates[0][2]) tells you exactly how deep the bad value sits — count the brackets against your source to find the nesting that's off.

FAQ

Does my data get uploaded to a server?

No. All the linting runs in your browser's memory, and the page works offline once loaded. Your GeoJSON never leaves your computer.

Why does it fail here but work in Leaflet/Mapbox?

Many mapping libraries are permissive — they fix data on the fly or ignore spec violations to get something on screen. This is a strict structural linter: it tells you what the spec actually requires, so your data travels between libraries instead of relying on one library's leniency.

What's the difference between this and a plain JSON linter?

A JSON linter only checks that brackets and commas are in the right place — and that is step one here. After that, this tool understands the geometry: it knows a Polygon is an array of rings, that rings must be closed, and that coordinates must be finite numbers in range.

Does it check the old "crs" object or winding order?

No. It validates the structure RFC 7946 requires and the coordinate ranges WGS84 implies. It does not flag a legacy crs member or enforce the right-hand rule for ring winding — those don't break the structural shape, so they aren't reported.

Is there a CLI version I can use for scripts?

Not from me — but geojsonhint on NPM is the long-standing command-line GeoJSON checker and covers similar ground.