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.

— S., [email protected]

GeoJSON Validator

updated 25 April 2026

GeoJSON input

Drop a .geojson / .json file, or

Validation report

Before you start

You need your GeoJSON data ready to go—either as a .geojson or .json file, or just the raw text sitting in your clipboard. I built this tool to check against RFC 7946, which is the modern standard for GeoJSON.

Keep in mind that while GeoJSON is "just JSON," it has very specific rules about how arrays are structured and what keys are allowed. If your data uses the old crs (Coordinate Reference System) object from the 2008 spec, my validator will flagged it as a note, since the modern spec mandates WGS84 exclusively.

There are no file size limits here because everything happens in your browser. If you can open the file in a text editor without your computer catching fire, this page should be able to lint it just fine.

How to use it

Paste your GeoJSON into the left pane, or drag-and-drop your file directly onto the text area.
Click Validate to trigger the spec-checker.
Read the Validation report in the right pane—I'll give you line numbers for syntax errors and specific reasons for spec violations.
If everything looks good, the status bar will turn green. If not, use the report to fix your source data and re-run.
Use Copy report if you need to share the error logs with a colleague or a bug tracker.

Example

Input (a simple Point feature):

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

Output (Success report):

✅ Valid GeoJSON (RFC 7946)
- Structure: Feature found.
- Coordinates: [102, 0.5] is a valid [lng, lat] pair.
- Properties: Valid object.

If I had swapped those coordinates to [0.5, 200.0], the report would immediately warn you that 200 is outside the valid latitude range of -90 → 90.

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 Antarctica, check your order with the GeoJSON Viewer.
Polygons must be closed. The first coordinate pair in a Polygon ring must be exactly identical to the last one. My validator checks this and will complain if they don't match, though the GeoJSON Formatter can help clean up your structure first.
At least four points for rings. A valid Polygon ring needs at least four points (the fourth being the closure of the triangle). Three points isn't a shape; it's just a LineString.
Winding order matters. RFC 7946 technically requires the "Right-Hand Rule" (outer rings are counter-clockwise). I'll show this as a note rather than a fatal error, as most maps still render "wrong" winding just fine.

Troubleshooting

I get a "Line 1: Unexpected token" error immediately.

This usually means your input isn't valid JSON at all. Check 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; you need to paste the actual file content.

The validator says my coordinates are out of range.

Check your order! Longitude must be between -180 → 180 and Latitude must be between -90 → 90. If you have [120, 45], that's fine. If you have [45, 120], you're trying to put a point 30 degrees past the North Pole.

My file is valid but "nested" features are failing.

GeoJSON doesn't allow nested FeatureCollections. You can have a GeometryCollection inside a Feature, but you cannot put a Feature inside another Feature's properties. I'll flag these structural breaks.

Related tools

See also: if you need to do something adjacent on this site, try GeoJSON Formatter to pretty-print or minify a GeoJSON file, GeoJSON to CSV to flatten a feature collection into a CSV table, or GeoJSON to KML to convert GeoJSON to KML for Google Earth.

Frequently asked questions

Does my data get uploaded to a server?

No. I value privacy and my own server costs. All the linting logic runs in your browser's memory. Your GeoJSON never leaves your computer.

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

Many mapping libraries are "permissive"—they try to fix your data on the fly or ignore spec violations to get something on the screen. My tool is a strict linter; it tells you what the spec actually requires so your data works everywhere, not just in one library.

Can this tool fix my winding order automatically?

Not yet. Right now it just identifies the issue. For automated fixing of winding order and self-intersections, I usually recommend using a tool like mapshaper or turf.js.

What is the difference between this and a JSON linter?

A JSON linter only checks if the brackets and commas are in the right place. My validator understands the geometry. It knows that a Polygon needs an array of arrays, and that coordinates must be finite numbers.

Is there a CLI version I can use for scripts?

I didn't write one, but you should check out geojsonhint on NPM. It's the gold standard for command-line GeoJSON validation and what inspired much of the logic here.