GeoJSON is the lingua franca of web mapping, but even small mistakes in the file structure can cause APIs to reject your data, map layers to silently disappear, or spatial queries to return nonsense results. Whether you export from QGIS, write coordinates by hand, or receive data from a third-party API, validation should be a routine step in your workflow. This guide explains why validation matters, what the spec requires, and how to validate your GeoJSON with GeoDataTools — for free, in your browser.

Why GeoJSON Validation Matters

Invalid GeoJSON fails in ways that range from obvious to infuriatingly subtle. A web API that consumes geographic data may return a 400 error with no useful message, leaving you to guess whether the problem is in the payload structure or the geometry itself. Mapping libraries like Mapbox GL JS and Leaflet often silently skip features they cannot parse, so a broken polygon simply does not appear on the map — no error, no warning, just missing data.

Desktop GIS tools are no more forgiving. QGIS may import a file that looks correct in the attribute table while drawing nothing on the canvas, because the coordinate values are structurally valid numbers but semantically wrong — latitude and longitude swapped, placing every feature in the middle of the ocean. Catching these errors early, before they propagate through a pipeline or reach production, is the core purpose of GeoJSON validation.

GeoJSON Spec Quick Reference

RFC 7946 is the authoritative specification for GeoJSON. The rules that cause the most real-world errors are worth keeping close at hand:

Coordinate order is [longitude, latitude]. This is the most frequently violated rule. The spec follows the mathematical (x, y) convention, so longitude comes first. Many datasets — especially those exported from GPS apps or spreadsheets — use the opposite order.
Altitude is optional and comes third. Positions may have two or three elements: [lon, lat] or [lon, lat, altitude]. Any additional elements are allowed by the spec but must be ignored by parsers.
Polygon rings must be closed. The first and last position in every ring must be identical. An unclosed ring is structurally invalid, and strict parsers will reject the file.
The right-hand rule governs winding order. Exterior rings must be counterclockwise; holes must be clockwise. Reversed winding order causes some renderers to fill the entire globe rather than the intended polygon.
No circular references. GeoJSON is a subset of JSON. Circular object references, sometimes introduced by in-memory JavaScript objects, are not serializable and will cause JSON.stringify to throw.
Seven geometry types only. Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, and GeometryCollection. Any other string in the "type" field is invalid.

For a full introduction to the format, see our guide on what is GeoJSON and learn about GeoJSON feature collections for working with multiple geometries in a single file.

How to Validate GeoJSON with GeoDataTools

The fastest way to validate a GeoJSON file is to upload it at geodata.tools/app. The validator checks both structure and geometry the moment your file is loaded:

Upload your file. Drag and drop a .geojson or .json file onto the map, or use the file picker. Files are processed entirely in your browser — nothing is sent to a server.
Read the error messages. If the file contains structural errors — missing required fields, invalid geometry types, unclosed rings — GeoDataTools displays a clear error message describing the problem and, where possible, the affected feature.
Inspect the map. Valid files render immediately on an interactive map. Visual confirmation is the fastest way to catch coordinate-order errors: if your features appear in the wrong country or ocean, the longitude/latitude values are almost certainly swapped.
Check the attribute table. Verify that feature counts and property values match your expectations. A mismatch between the number of features in the file and the number rendered on the map usually means some features failed to parse.

You can also explore all converter tools on GeoDataTools to transform your data between formats — conversion pipelines often introduce the very errors described in this guide.

Common GeoJSON Errors and How to Fix Them

Wrong Coordinate Order (Latitude/Longitude vs Longitude/Latitude)

RFC 7946 requires [longitude, latitude], but WGS84 GPS data, Google Maps URLs, and many spreadsheet exports provide [latitude, longitude]. The symptom is unmistakable: features appear far from their intended location, often reflected across the equator or prime meridian. Fix this by swapping the first two elements in every coordinate pair. In JavaScript, map each position array with ([a, b, ...rest]) => [b, a, ...rest].

Unclosed Polygon Rings

A polygon ring is valid only when its first and last positions are identical. Some tools silently close rings on import, masking the error until a stricter consumer rejects the file. The fix is simple: append a copy of the first coordinate to the end of each ring array. For example, a ring starting at [0, 0] must also end at [0, 0].

Invalid Geometry Types

The "type" field is case-sensitive and must exactly match one of the seven values defined in RFC 7946. Common typos include "polygon" (lowercase), "Multipolygon" (wrong casing on the second word), and "Feature Collection" (space instead of no separator). Parsers reject unrecognised type strings outright, so the entire feature or geometry is dropped.

Missing Required Fields

Every GeoJSON object requires a "type" member. A Feature additionally requires "geometry" and "properties" (which may be null, but must be present). A FeatureCollection requires a "features" array. Omitting any of these causes schema validation to fail. When generating GeoJSON programmatically, use an established library rather than hand-crafting the JSON object to ensure all required fields are present.

NaN or Null Coordinates

Coordinate arrays that contain null, undefined, or NaN values are not valid JSON numbers. They typically originate from failed unit conversions, missing data in a CSV, or serialization bugs. The JSON spec requires that all numbers are finite, so these values must be replaced or the affected features removed before the file can be considered valid.

Online GeoJSON Validators

Several browser-based tools can validate GeoJSON without any installation:

geojsonlint.com — Paste GeoJSON text and receive immediate RFC 7946 schema validation. It identifies structural errors and reports which part of the document is invalid. Best for quick, one-off checks.
jsonlint.com — Validates that your file is well-formed JSON before GeoJSON-specific checks are even possible. If your file contains trailing commas, unquoted keys, or JavaScript-style comments, start here.
GeoDataTools — Combines schema validation with visual rendering. Structural errors are reported as messages; geometric errors (wrong coordinate order, winding issues) are revealed by seeing where features actually appear on the map. This is the most complete free option for validating both the structure and the spatial correctness of a GeoJSON file.

Programmatic Validation

For automated pipelines, unit tests, or build-time checks, you need a library rather than a browser tool.

JavaScript / Node.js with Turf.js:

import booleanValid from '@turf/boolean-valid';

const isValid = booleanValid(myFeature);
if (!isValid) {
  console.error('Geometry is not topologically valid');
}

booleanValid from @turf/boolean-valid checks for geometric validity beyond schema correctness — it catches self-intersecting rings and other topological problems that schema validators miss. Pair it with the geojson-validation npm package for full RFC 7946 schema coverage.

Python with the geojson library:

import geojson

with open('data.geojson') as f:
    gj = geojson.load(f)

errors = geojson.errors(gj)
if errors:
    for error in errors:
        print(f'Validation error: {error}')
else:
    print('File is valid GeoJSON')

The geojson Python package provides geojson.errors() which returns a list of RFC 7946 violations. It integrates naturally into data-processing scripts and pytest test suites. For broader geometric validation, use Shapely's is_valid attribute on each geometry.

Preventing GeoJSON Errors at the Source

The most effective validation strategy is to avoid introducing errors in the first place. The biggest source of invalid GeoJSON is manual JSON editing — it is easy to forget to close a ring, misspell a type name, or omit a required field when writing coordinates by hand.

Use official libraries to generate GeoJSON wherever possible. In JavaScript, the @turf/helpers package provides point(), polygon(), lineString(), and featureCollection() factory functions that always produce spec-compliant output. In Python, the geojson package offers equivalent constructors. In QGIS, export using the built-in GeoJSON driver and verify the CRS is set to EPSG:4326 before export, since GeoJSON coordinates must be in WGS84 geographic coordinates.

When receiving GeoJSON from an external API, validate on ingestion rather than assuming the data is correct. A lightweight schema check at the entry point of your pipeline prevents malformed data from propagating into databases, rendering layers, or downstream services. Combined with the visual confirmation that GeoDataTools provides, this approach makes broken GeoJSON a rare exception rather than a routine debugging task.

How to Validate GeoJSON Online — Free Tools and Common Errors