A geospatial file that parses without an error and one whose coordinates are actually correct are two different guarantees. A swapped coordinate pair, a Shapefile still in the wrong projection, or coordinates rounded to uselessness all produce a file that's completely well-formed — nothing about the format itself catches any of them. The only reliable check is plotting the data on an actual map and looking, and it's the step that's easiest to skip when a conversion or export "completes successfully" with no errors.
Errors that only show up visually
Coordinate order swapped. This is the single most common geospatial data bug, by a wide margin. GeoJSON, KML, and WKT all store coordinates as [longitude, latitude]; GPX and plenty of hand-entered data use the conventional "lat/lon" order instead. Mix the two up and you don't get an error — you get a point that's technically valid and often thousands of kilometers from where it should be. A point plotted in the ocean where a city should be is the classic symptom.
A Shapefile still in its original projection. Shapefiles are frequently stored in a projected coordinate system (UTM, State Plane) rather than plain latitude/longitude. If a .prj file is missing or misread and the coordinates get treated as WGS84 lat/lon without actually being reprojected, every point lands in a plausible-looking but wrong location — not obviously broken, just wrong, which is worse than an outright error.
Coordinates rounded to too few decimal places. Each decimal place of latitude/longitude precision is worth roughly a 10x change in real-world accuracy — 2 decimal places is only accurate to about a kilometer, which is invisible in the raw numbers but obvious the moment a point that should be on a specific street ends up several blocks away.
None of these three throw a parse error. All three are visible in about a second once the data is actually rendered on a map.
Catching a bad projection before you even look
The Shapefile-projection failure above is deterministic, not just visual — a coordinate is either inside the valid latitude/longitude range or it isn't. The Geo QA & CRS Inspector reads a Shapefile's .prj file directly, reprojects to WGS84 when it can, and flags exactly this case — a .prj that's missing or unreadable, with coordinates left far outside the valid range — without needing you to spot it on a map first. It also checks structural geometry (unclosed polygon rings, wrong ring winding order, antimeridian crossings) across GeoJSON, KML, GPX, and the other formats, not just Shapefile. Once you know that's the problem, the Geo Reprojection & Repair Workbench fixes it — reproject to WGS84 with a UTM zone or a pasted CRS definition, and the same tool closes invalid rings and fixes wrong winding order automatically — see how to reproject a Shapefile without a desktop GIS.
Checking a file, not just trusting it
The GeoJSON / KML / GPX / CSV Viewer renders a file's points, lines, and polygons directly on an interactive map — upload it and look, rather than trusting that a conversion or export worked. A few things make this more useful than a quick glance:
- Multiple files, each in its own color — useful for comparing a converted file against its source, or checking several tracks at once.
- The Table tab — every feature as a row instead of a pin on a map, useful for spot-checking property values (names, timestamps, categories) alongside the geometry.
- Click any feature for its full property list, not just whatever label happens to be visible on the map.
- A standalone distance/area calculator in the same tool — click points directly on the map to measure a real-world distance or area, no file needed, useful for sanity-checking that a shape is roughly the size it should be.
What to actually look for
Three checks cover most real geospatial data problems:
- Is everything on the right continent? Sounds basic, but it's exactly what a coordinate-order swap or a botched reprojection produces — a point that's numerically valid and geographically nonsensical.
- Does the shape look right? A polygon that should be a neighborhood boundary but renders as a thin sliver, or a track that jumps impossibly between two points, both indicate a real data problem, not just an unusual location.
- Do the properties match what you expect? Click a few features and check the Table tab — a property that's blank, mislabeled, or in the wrong column is common after a conversion between formats with different property-handling conventions (see how to convert between GeoJSON, KML, GPX, and other geospatial formats).
A file that passes all three on a representative sample is one you can reasonably trust. One that doesn't is worth fixing before it feeds into anything downstream.