What is a .prj file in GIS?

A .prj file is the small sidecar file in a shapefile dataset that stores the coordinate reference system as Well-Known Text (WKT). It tells GIS software the datum, units, and projection of the coordinates in the .shp file so they can be placed and transformed correctly.

What happens if a shapefile has no .prj file?

The geometry in the .shp file is intact, but software has no declared CRS, so it cannot know how to place or transform the features. Depending on the tool, the layer may be treated as unknown CRS, defaulted to something wrong, or refuse to align with other layers, and measurements become unreliable.

How do I recreate a missing .prj file correctly?

First confirm the true CRS by inspecting the coordinate ranges and comparing the data against a trusted reference, then write the matching WKT, for example with ogr2ogr -a_srs EPSG:32631 or gdalsrsinfo, or by setting the layer CRS in QGIS and exporting. Define the CRS only when the coordinates are genuinely in it; do not move the data.

Why shouldn't I just copy a .prj file from another shapefile?

Copying a .prj only relabels the coordinates; it never reprojects them. If the donor .prj describes a different CRS than the data actually uses, every feature is now mislabeled and will plot in the wrong place. Only reuse a .prj when you are certain both datasets share the same CRS.

What Is a .prj File? Shapefile CRS Explained

Short answer

A .prj file is the small companion file in a shapefile dataset that records the layer's coordinate reference system (CRS) as Well-Known Text (WKT). It does not store geometry; the .shp file holds the coordinates. The .prj is what tells software what those coordinates mean, the datum, ellipsoid, units, and projection, so the features can be placed on the Earth and transformed correctly. Lose it, and you still have geometry but no idea where on the planet it belongs.

A shapefile is a set of files

A "shapefile" is not one file. It is a small family that must travel together, and each member has a job:

.shp — the geometry (points, lines, polygons) as raw coordinate pairs.
.shx — a positional index into the .shp.
.dbf — the attribute table (dBASE format).
.prj — the CRS definition, in WKT.
Optional: .cpg (attribute text encoding), .qix/.sbn (spatial indexes), .shp.xml (metadata).

The first three are mandatory and contain the data itself. The .prj is technically optional in the format, which is exactly why it goes missing so often, someone zips up .shp/.shx/.dbf and forgets the rest. But without it the coordinates are ambiguous: the numbers 450000, 5400000 could be UTM meters in dozens of zones, and 2.35, 48.85 could be degrees on any of several datums.

What is inside a .prj file

Open a .prj in a text editor and you see a single line of WKT (Well-Known Text), a human-readable, machine-parseable description of the CRS. For WGS84 geographic coordinates (EPSG:4326) it looks like:

GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",
SPHEROID["WGS_1984",6378137.0,298.257223563]],
PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]

For a projected CRS such as UTM 31N (EPSG:32631) it is longer, nesting the underlying geographic CRS inside a PROJCS block that adds the Transverse Mercator projection, its parameters (central meridian, false easting 500000, scale factor), and UNIT["Metre",1.0].

Two things matter here. First, WKT describes the CRS by parameters, not by EPSG number, so a .prj may or may not carry the EPSG authority code; tools match it back to a code by comparing parameters, which occasionally fails for near-identical definitions (the classic Esri "GCS_WGS_1984" WKT vs the EPSG WKT). Second, there are WKT dialects (the older ESRI WKT and the newer OGC WKT2). Most software reads both, but subtle differences in datum names can cause a tool to flag the CRS as "unknown" even when the geometry is fine.

What breaks when the .prj is missing

The geometry survives, but the consequences cascade:

Unknown CRS. QGIS marks the layer with an unknown-CRS warning and may apply the project default CRS for display, which is usually wrong.
Wrong placement. If software guesses or defaults, the layer can appear in the ocean, at null island (0,0), or simply not overlay your other data.
No reprojection. You cannot transform a layer whose source CRS is unknown, because transformation needs a defined starting point. Every downstream step is blocked or wrong.
Broken measurements. Distance, area, and buffer results depend on units the missing .prj would have declared.

Worked example: diagnose, then repair

A colleague sends boreholes.shp (with .shx and .dbf) and no .prj. Do not guess. Diagnose:

# What does GDAL see? Note the coordinate extent and any SRS.
ogrinfo -al -so boreholes.shp

Read the extent. Suppose it reports Extent: (399000, 5398000) - (412000, 5411000). Those six-figure values in the hundreds of thousands and millions are meters, which means a projected CRS (UTM-like), not degrees. Compare against where the boreholes should be: if the project is in France around 2.5°E, that is UTM zone 31N, so the true CRS is almost certainly EPSG:32631.

Now confirm before committing. The strongest confirmation is to define the candidate CRS temporarily and overlay against trusted reference data (a national basemap, known control points). If the features land in the right place, the candidate is correct.

Once confirmed, write the .prj by defining the CRS, an operation that changes no coordinates:

# Write a correct .prj by defining the source CRS (no coordinates move)
ogr2ogr -a_srs EPSG:32631 boreholes_fixed.shp boreholes.shp

In QGIS, the equivalent is Layer Properties → Source → set CRS, or right-click → Export → Save Features As with the correct CRS chosen as the source (not a reprojection target). To inspect or generate WKT directly:

gdalsrsinfo -o wkt EPSG:32631 > boreholes.prj

If you actually need the data in a different CRS afterwards (say WGS84 for a web map), that is a separate reprojection step with a known source:

ogr2ogr -t_srs EPSG:4326 boreholes_wgs84.shp boreholes_fixed.shp

How to read coordinate ranges as a fingerprint

When the .prj is gone, the coordinate values themselves are your best evidence, because different CRS families produce numerically distinct signatures. Learning to read them turns guesswork into diagnosis:

Longitude/latitude degrees (e.g. EPSG:4326): small numbers, longitude in [−180, 180], latitude in [−90, 90], usually with several decimal places (2.3522, 48.8566). If you see values bounded by ±180/±90, it is almost certainly geographic.
UTM meters (EPSG:326##/327##): eastings roughly 100,000–900,000 (centered near 500,000 because of the false easting), northings from 0 up to ~9,300,000 in the southern hemisphere. Six- and seven-figure integers are the tell.
National grids: distinctive offsets baked in. British National Grid eastings/northings run 0–700,000 / 0–1,300,000; Lambert-93 (France) sits around 600,000–1,200,000 easting and 6,000,000–7,200,000 northing. The specific magnitude band points to the grid.
State Plane (US, feet): very large numbers, often in the millions of feet, because of large false origins.

Combine the magnitude signature with where you know the data should be. If the extent says easting ~600,000, northing ~6,800,000 and the site is in France, Lambert-93 (EPSG:2154) is a strong candidate; if the same eastings appear but the site is in Britain, British National Grid (EPSG:27700) fits. This is hypothesis generation, not proof: always confirm with a reference overlay before writing the .prj.

Common pitfalls and why they happen

Copying a .prj from an unrelated layer. This only relabels; it never moves coordinates. If the donor CRS differs from the data's actual CRS, every feature is now mislabeled. People do it because the missing file looks like a trivial gap, but it is a CRS assertion, not a placeholder.
Guessing from the filename or folder name. "utm.shp" tells you nothing reliable; only the coordinate values and a reference check do.
Assigning EPSG:4326 to projected data. The reflex "just set it to WGS84" stamps degrees onto meter coordinates and flings the data thousands of kilometers away.
WKT dialect mismatches. An Esri-flavored .prj may be flagged "unknown" by a stricter reader even though the data is correct; regenerate clean WKT from the EPSG code.
Ignoring the difference between define and transform. Defining (write .prj) is for missing/wrong metadata on correct coordinates; transforming is for moving coordinates between known systems. Mixing them up is the root of most shapefile placement bugs.

QA and validation

After writing a .prj, overlay the layer on trusted reference data and confirm it lands where the features physically are.
Run a measurement check: a known fence line, road segment, or parcel area should match its real length/area within tolerance.
Re-read the CRS with gdalsrsinfo boreholes.shp and confirm it resolves to the EPSG code you intended, not just "unknown."
If you plan to migrate off shapefiles, consider GeoPackage or GeoJSON, where the CRS is embedded in the file and cannot be separated and lost.

Bathyl perspective

We treat a missing .prj as a diagnosis problem first and a file problem second: confirm the true CRS from coordinate ranges and a reference overlay before writing anything, and never copy a .prj between datasets on faith. Because the CRS can be physically detached from a shapefile, we prefer formats that carry it internally for anything that will be reused or handed off.

What Is a PRJ File?