Geo QA & CRS Inspector
Inspects a geo file's coordinate reference system and runs deterministic quality checks over its geometry. GeoJSON, KML, and GPX are WGS84 by specification, so CRS inspection there mostly confirms that and flags an older GeoJSON export's deprecated top-level "crs" member. A Shapefile .zip is where CRS actually varies: its .prj file is read and used to reproject to WGS84 when it parses; when there's no .prj at all, coordinates are checked exactly as stored — catching this tool's headline bug, a Shapefile in UTM meters or State Plane feet loaded as if it were already lon/lat. Every file, regardless of format, is also checked for out-of-range coordinates, lines or rings with too few points, unclosed polygon rings, wrong ring winding order (RFC 7946 §3.1.6), and antimeridian crossings. Findings are grouped by problem type, the same way as the YOLO/COCO/Pascal VOC dataset health checkers. Nothing is uploaded; every file is read and checked in your browser.
GeoJSON, KML, GPX, CSV, WKT, TopoJSON, or a Shapefile .zip (.shp + .dbf + .prj) — mix and match, each file is checked independently. Nothing is uploaded; every file is read directly in your browser.
About this tool
This tool inspects a geo file's coordinate reference system and runs deterministic quality checks over its geometry — the two things that usually only surface once a map renders in the wrong place or a GIS import fails outright. GeoJSON, KML, and GPX are WGS84 lon/lat by specification, so for those formats "CRS inspection" mostly means confirming that and flagging the one real exception: an older GeoJSON export's legacy top-level "crs" member, which RFC 7946 says conforming readers must ignore — worth surfacing so it's clear why setting it has no effect. A Shapefile .zip is the format where CRS actually varies: its .prj file is read and, when it parses, used to reproject every coordinate to WGS84 automatically; when there's no .prj at all, or it can't be parsed, coordinates are used exactly as stored and checked as-is — which is precisely how this tool catches its headline bug: a Shapefile in UTM meters or State Plane feet, loaded as if it were already lon/lat. Beyond CRS, every file (regardless of format) is checked for coordinates outside the valid WGS84 range, lines or polygon rings with too few points to mean anything, polygon rings whose first and last positions don't match (a GeoJSON spec requirement plenty of exporters get wrong), ring winding order against RFC 7946 §3.1.6 (exterior rings counterclockwise, holes clockwise), and antimeridian crossings — an edge whose longitude jumps more than 180° in one step, almost always an unhandled ±180° dateline crossing. Findings are grouped by problem type, worst first, the same way as the YOLO/COCO/Pascal VOC dataset health checkers. Nothing is uploaded; every file is read and checked in your browser.
Supported formats
- GeoJSON (.geojson, .json) — Checked directly; its legacy top-level "crs" member (if present) is flagged as deprecated and ignored.
- KML (.kml) — WGS84 by specification — no CRS to inspect, only the structural geometry checks apply.
- GPX (.gpx) — WGS84 by specification — same as KML.
- CSV (.csv) — A lat/lon CSV, parsed the same way as the Geo Viewer and Geo Format Converter.
- WKT (.wkt) — Well-Known Text geometry, one per line.
- TopoJSON (.topojson) — Decoded to GeoJSON-shaped geometry before checking.
- Shapefile (.zip) — A .zip containing at least a .shp — its .prj (if present) drives CRS detection and reprojection to WGS84.
What you can do
- Inspect GeoJSON, KML, GPX, CSV, WKT, TopoJSON, or a Shapefile .zip — mix formats in one check
- Detects the real-world bug this tool exists for: projected coordinates loaded as if they were already WGS84
- Also checks ring winding order, unclosed rings, too-few-point lines, and antimeridian crossings
- Nothing is uploaded — every file is read and checked entirely in your browser
How to use
Step 1
Pick one or more geo files
GeoJSON, KML, GPX, CSV, WKT, TopoJSON, or a Shapefile .zip — each file is checked independently.
Step 2
Checks run automatically
CRS is detected (or assumed) per file, then every coordinate and ring is validated.
Step 3
Review the findings
Grouped by problem type, worst first — expand any group to see exactly which file and feature it's in.
Example
A finding looks like this:
GEO.COORDINATE_OUT_OF_RANGE
parcels.zip — Feature #14 has a coordinate (583482, 4506112) outside the valid WGS84 range (longitude -180..180, latitude -90..90) — likely un-reprojected data.
That's a Shapefile with no .prj file, so its raw UTM easting/northing values were checked as-is instead of being silently treated as lon/lat — exactly the mismatch this tool is built to catch.
How your data is handled
This tool is labeled 🟢 Browser: every file is read directly via your browser's File API and every check runs entirely client-side — nothing is uploaded, and there's no server involved anywhere in this tool. No AI model is used; every check is a deterministic rule, not a prediction.
Frequently asked questions
Why does it say my GeoJSON's CRS is "assumed WGS84" — can't it tell for sure?+
GeoJSON (RFC 7946) is defined to always be WGS84 lon/lat — there's no other CRS a valid file can declare that current readers respect. "Assumed" reflects that this is a specification requirement, not a guess; the only exception is the legacy "crs" member some older exports still carry, which is flagged separately since it's ignored rather than honored.
My Shapefile shows GEO.CRS_MISSING and GEO.COORDINATE_OUT_OF_RANGE together — what does that mean?+
No .prj file was found in the bundle, so its coordinates were checked exactly as stored rather than being reprojected. If they're then out of the valid lon/lat range, that's strong evidence the Shapefile uses a projected CRS (UTM, State Plane, etc.) and needs its .prj file to be usable — or reprojection needs to happen with the correct CRS supplied separately.
What's wrong with a ring wound the "wrong" direction? My map renders it fine.+
Most renderers (including the map libraries used elsewhere on this site) tolerate either winding order and render it correctly regardless. RFC 7946 §3.1.6 still specifies a direction, though, and some stricter tools — particularly ones computing area or point-in-polygon tests — get it wrong on a reversed ring. It's reported as a warning, not an error, because it's often harmless in practice.
Why is an antimeridian crossing only an observation, not an error?+
A longitude jump of more than 180° between two consecutive points is ambiguous by nature — it usually means an unhandled ±180° dateline crossing, but it can also be genuinely intended data (a very wide line spanning most of the globe). It's surfaced for you to check, not flagged as definitely wrong.
Does this reproject my file, or just check it?+
Only Shapefile input is reprojected — and only for the purpose of running these checks and showing you the result; nothing is downloaded or modified. GeoJSON/KML/GPX/CSV/WKT/TopoJSON are already WGS84 by spec, so there's nothing to reproject.
Can it detect a swapped latitude/longitude?+
Not directly — a genuine lat/lon swap where both values still land in-range (e.g. a coordinate that's valid either way round) can't be told apart from correct data without knowing where the feature is actually supposed to be, so this tool doesn't guess. It does catch the more common and more damaging version of this mistake: a swap (or a raw projected coordinate) that lands outside the valid range entirely, via GEO.COORDINATE_OUT_OF_RANGE.