A Shapefile with no .prj file — or one that's corrupted, or simply missing from a .zip someone put together by hand — has its coordinates read exactly as stored. If those coordinates are actually UTM eastings and northings, or State Plane feet, and not lon/lat at all, every point ends up somewhere between "wrong" and "on the wrong continent." The traditional fix is opening a desktop GIS, importing the file, and setting the CRS by hand. This is the browser-only version of that one step.
Diagnosing first
Before fixing anything, confirm reprojection is actually the problem. The Geo QA & CRS Inspector reads a Shapefile bundle the same way any import would: if there's no .prj, it reports GEO.CRS_MISSING; if there's one but it can't be parsed, GEO.CRS_UNPARSEABLE; and either way, if the resulting coordinates fall outside the valid WGS84 range, GEO.COORDINATE_OUT_OF_RANGE — the actual symptom of the projection problem, not just its cause. Seeing both of those together on the same file is the clearest possible signal that what follows is worth doing.
Reprojecting without an EPSG lookup
The Geo Reprojection & Repair Workbench offers two ways to tell it what CRS a file's coordinates are actually in:
- UTM zone. If you know (or can guess from the coordinate magnitudes — six or seven digits, not two or three) that the source is UTM, just supply the zone number and hemisphere. Every one of UTM's 120 zones is computed from a fixed formula (
+proj=utm +zone=N +datum=WGS84 +units=m +no_defs), so there's no code to look up. - A pasted CRS definition. For anything else — State Plane, a national grid, a CRS with a proper EPSG code — search it on epsg.io or spatialreference.org and copy its WKT or proj4 text, not just the number, into the definition field. That text is exactly what a working
.prjfile already contains.
Either way, the tool reprojects every coordinate to WGS84 using the same logic already relied on when a Shapefile's own .prj parses successfully — this is that same path, with the CRS supplied by you instead of read from the file.
Fixing geometry at the same time
A Shapefile assembled or edited by hand often has structural problems alongside the projection one: a polygon ring that doesn't close, or one wound the wrong direction per the GeoJSON winding convention. The same tool fixes both automatically — closing a ring and reversing its winding are both lossless (neither can change what shape a ring represents, only whether it's technically valid), so there's no toggle for them. A feature whose line or ring has too few points to mean anything is flagged separately and only removed if you explicitly ask for it, since that's the one operation that actually deletes something.
Confirming it worked
Run the repaired output back through the Geo QA & CRS Inspector — the coordinate-range and geometry findings that motivated the fix should be gone. For a visual check, the GeoJSON / KML / GPX / CSV Viewer renders the result on an actual map, which is still the fastest way to confirm a reprojection landed the data somewhere that actually makes sense.
Where each step happens
- Diagnosing — the Geo QA & CRS Inspector confirms a projection problem is actually the issue before you reproject anything.
- Reprojecting and repairing — the Geo Reprojection & Repair Workbench is the tool this guide is built around.
- Confirming the result — the GeoJSON / KML / GPX / CSV Viewer renders the repaired file on a map for a final visual check.