Fix: "The CRS of a Map Projection Could Not Be Parsed" (QGIS Error Guide)

This QGIS error means the .prj file accompanying your shapefile contains corrupt, truncated, or non-standard WKT that QGIS cannot recognise. Upload your shapefile to Projection Finder to extract a valid CRS from the coordinates themselves, then download a correctly formatted .prj file to replace the broken one.

You've opened a Shapefile or raster in QGIS and hit this message: The CRS of a map projection could not be parsed. The layer loads — or doesn't — and the coordinates land somewhere wrong, or the CRS field shows blank.

This isn't a minor warning. It means QGIS tried to read the projection definition from your file and found something it cannot interpret. The data may still be usable, but until the CRS is fixed, any measurements, overlays, or exports will be unreliable.

This guide walks through what causes the error, how to diagnose it, and how to fix it — in both QGIS and ArcGIS.

What This Error Actually Means

QGIS reads CRS information from a .prj file (for Shapefiles) or embedded metadata (for GeoTIFF, GeoPackage, etc.). The .prj file contains a WKT (Well-Known Text) string — a structured text format that describes the coordinate reference system: datum, projection type, units, parameters.

When QGIS says the CRS "could not be parsed," it means the WKT it found is either malformed, empty, in an unrecognised format, or contains characters that break the parser. The layer has no usable CRS until you assign one manually.

The Most Common Causes

1. Empty or Zero-Byte .prj File

The .prj file exists alongside your .shp but contains nothing — or a single blank line. This happens when files are exported with incomplete metadata, or when a .prj is created as a placeholder that never gets populated.

Check: open the .prj file in a text editor. If it's blank or shows only whitespace, that's the problem.

2. ESRI WKT Format That QGIS Cannot Parse

ArcGIS writes .prj files using ESRI-dialect WKT. This dialect uses different naming conventions from the OGC standard and often omits the AUTHORITY["EPSG","XXXX"] tag that QGIS relies on for matching.

Older QGIS versions (pre-3.x) are particularly sensitive to this. You'll see the parse error even when the WKT looks reasonable, because the parser doesn't recognise the ESRI naming scheme.

3. Custom or Non-Standard Projection

If the data was created in a custom CRS — a modified UTM zone, a local grid, or a national projection not in the main EPSG registry — QGIS may not be able to match it to any known definition. The WKT itself might be valid, but QGIS has no record of that projection.

4. Encoding Issues

A .prj file saved with a BOM (Byte Order Mark) at the start, or in a non-UTF-8 encoding, can cause parse failures even when the WKT content is otherwise correct. This is most common on files created on Windows with older software.

Check: open the file in a hex editor or a text editor that shows encoding. If you see EF BB BF at the very start (UTF-8 BOM) or unusual characters before the opening bracket, encoding is the issue.

5. Truncated or Corrupt WKT

The WKT string was cut off mid-way — mismatched brackets, missing closing tokens, or a file that was partially written and never completed. WKT relies on balanced bracket nesting; a single missing closing bracket makes the entire string unparseable.

Step-by-Step Fix in QGIS

Step 1: Check What's in the .prj File

Before changing anything in QGIS, open the .prj file in a plain text editor (Notepad, TextEdit, VS Code). You're looking for:

• Is the file empty? → Cause is a missing or blank .prj
• Does it start with PROJCS[ or GEOGCS[? → Valid WKT structure, likely an ESRI format or encoding issue
• Are the brackets balanced? Count opening and closing brackets — they must match
• Are there unusual characters at the very start? → Encoding issue

Step 2: Assign the CRS Manually in QGIS

If you know (or can determine) the correct CRS:

1. Right-click the layer in the Layers panel and select Layer Properties
2. Go to the Source tab
3. Click Set source CRS (the button next to the CRS field)
4. Search for the EPSG code or projection name and select it
5. Click OK and then Apply

This tells QGIS how to interpret the coordinates without modifying the underlying file.

Step 3: Replace the .prj Content

If the .prj file is empty, corrupt, or ESRI-format and you know the correct EPSG code:

1. Go to epsg.io and search for your EPSG code
2. Click Export and copy the OGC WKT string
3. Open your .prj file in a text editor
4. Delete all existing content and paste the OGC WKT string
5. Save the file as UTF-8 (no BOM)
6. Reload the layer in QGIS

Step 4: Export with Correct CRS

Once you've assigned the correct CRS manually in QGIS (Step 2), you can make the fix permanent by re-exporting:

1. Right-click the layer → Export → Save Features As
2. Set the CRS to your corrected EPSG code
3. Save to a new file

The exported file will have a correctly formed .prj file and the error will not reappear.

Step-by-Step Fix in ArcGIS

ArcGIS provides the Define Projection tool specifically for this situation. It overwrites the .prj file with a valid definition.

1. Open ArcToolbox (or the Geoprocessing pane in ArcGIS Pro)
2. Navigate to Data Management Tools → Projections and Transformations
3. Open Define Projection
4. Set the input dataset to your layer
5. Click the coordinate system selector and choose the correct CRS
6. Click Run

After running, the .prj file will be replaced with a valid ESRI WKT definition. The layer should then load without errors in both ArcGIS and QGIS.

How to Find the Correct CRS When You Don't Know It

The hardest part of this error is often not the fix — it's identifying which CRS the data is actually in. If the .prj is corrupt or missing, you have to work backwards from the coordinate values.

Read the Coordinates Directly

Open the attribute table or use Identify Features in QGIS to read a few coordinate pairs. Then ask:

• Are x values between -180 and 180, and y values between -90 and 90? The data is likely in a geographic CRS (latitude/longitude). EPSG:4326 (WGS84) is the most common.
• Are x values large numbers like 500000 or 612000? The data is in a projected CRS using metres. This could be UTM, a national grid, or a state/local projection.
• Are x values around 6,000,000–8,000,000 and y values similar? Possibly a Transverse Mercator or similar projection with a large false easting/northing.
• Are values in the millions with a recognisable false origin? Check national grid systems for the country the data covers.

Use the Geographic Extent as a Clue

If you know roughly where the data should be geographically — a city, a country, a region — you can narrow down the CRS candidates significantly. Most countries use a defined set of official projections, and UTM zones are predictable by longitude.

Using Projection Finder to Detect the CRS Automatically

If reading coordinates manually isn't enough, Projection Finder automates the analysis. Upload your file — Shapefile, GeoTIFF, GeoJSON, or CSV — and the tool:

• Extracts whatever CRS information exists in the file (even partial or corrupt metadata)
• Analyses the coordinate values and range
• Ranks likely CRS candidates by confidence
• Shows a map preview so you can verify the result visually

When the CRS is extracted from valid metadata, it's shown as FOUND. When inferred from coordinates, it's shown as GUESSED — which is honest: it's a strong candidate, not a certainty. If the coordinates are too ambiguous to narrow down, it returns UNKNOWN and asks you to select manually.

When This Does NOT Help

There are situations where the steps above won't fully resolve the problem:

• Truly custom projections. If the data was created in a local engineering or survey grid with no EPSG code, you'll need the original projection parameters from the data producer. No tool can recover parameters that were never recorded.
• Data from classified or proprietary systems. Some government or military datasets use non-public projection definitions. These can't be matched against public registries.
• Corrupt coordinate data. If the coordinates themselves are garbled — not just the metadata — fixing the CRS won't make the data display correctly.
• Mixed CRS within a single file. Some datasets contain features from multiple projections. Assigning a single CRS to the whole file won't produce correct results.

Preventing This Error in Future

A few practices that prevent CRS parse errors from appearing in the first place:

• Always keep the .prj file with the .shp when moving or copying data. Shapefiles require all component files — .shp, .dbf, .shx, and .prj — to stay together.
• When exporting from ArcGIS for use in QGIS, prefer GeoPackage or GeoJSON formats — they embed the CRS definition inside the file rather than in a separate .prj.
• After any export or format conversion, verify the CRS loaded correctly before doing any analysis.
• If you're receiving data from others, ask them to confirm the EPSG code and include it in the delivery documentation.

FAQ

Related Guides

• Find Shapefile Projection — Free .prj Checker & Fixer
• How to Convert WKT to EPSG Code
• Fix GeoJSON Projection — Why Coordinates Show in the Ocean
• Find GeoTIFF Projection — Read CRS from Any Raster File
• Why Is My GIS Data Showing at 0,0? (Null Island)

Related Resources

• EPSG.io — Search and look up EPSG codes, download OGC WKT
• spatialreference.org — CRS definitions in multiple formats including OGC WKT and ESRI WKT
• I Hate Coordinate Systems — Troubleshooting guide for projection problems