Short answer

In QGIS there are several coordinate systems in play at once, and confusing them is the root of most "my data is in the wrong place" and "my measurements are wrong" problems. The layer CRS is the coordinate system the data is actually stored in — it tells QGIS what the numbers in the file mean. The project CRS is purely a display setting for the map canvas; QGIS reprojects every layer to it on the fly so they overlay correctly, without changing any stored coordinates. A third, separate decision is the CRS your analysis and exports run in. Treat these as independent choices and the confusion disappears.

Why one map shows several CRS at once

QGIS performs on-the-fly (OTF) reprojection: it can draw layers stored in different CRSs together by transforming each one to the project CRS just for display. This is genuinely useful — you can drop a WGS84 GPS track, a UTM orthophoto, and a national-grid cadastre onto one canvas and they line up. But it has a side effect: because everything looks aligned, it is easy to forget that the layers are not actually in the same system, and that the canvas alignment says nothing about whether a measurement will be correct.

The mental model that works:

  • Layer CRS = the truth about the data. Set wrong, the layer lands in the ocean or the wrong continent.
  • Project CRS = the lens you view through. Set wrong, everything still draws (OTF handles it) but the displayed coordinates and on-screen measure tool use it.
  • Processing/analysis CRS = where the math happens. This is what determines whether your slope, buffer, area, and distance are right.
  • Export CRS = what the next tool or person receives. Not automatically the project CRS.

"It lines up but measures wrong" — explained

This is the classic trap. Suppose your project CRS is EPSG:3857 (Web Mercator) because you added an OpenStreetMap basemap, and your data is a UTM cadastre. Everything overlays perfectly. Then you measure a parcel and the area is too large.

The reason: Web Mercator is a conformal projection that grossly inflates area away from the equator — by roughly a factor of 1/cos²(latitude), which at 50°N is about 2.4×. The map looks fine because shape and alignment are preserved; area is not. The fix is to run the measurement or analysis in an appropriate projected CRS (a local UTM zone, a national grid, or an equal-area projection for area work), regardless of what the canvas displays. In QGIS, the Measure tool and field calculator let you choose the CRS the calculation uses; do not leave it on a basemap-driven Web Mercator project CRS.

A subtler version: computing area or distance directly from layers in EPSG:4326. The coordinates are degrees, so unless you use the ellipsoidal/geodesic option, "area" comes out in square degrees — meaningless. Set the project to use ellipsoidal measurement, or reproject to a metric CRS first.

Setting each one correctly

Layer CRS — only declare what is true. If a layer has no CRS or the wrong one, fix it by assigning only when you know the coordinates are genuinely in that system but the metadata was lost. Right-click the layer, Layer CRS → Set Layer CRS, and choose the CRS the numbers are actually in. Assigning a CRS does not move the data; it relabels what the existing coordinates mean.

Reprojecting — when the coordinates must change. If the data is in CRS A and you need it in CRS B, that is a transformation, not an assignment. Use Vector → Data Management → Reproject Layer (the qgis:reprojectlayer algorithm) or Raster → Projections → Warp (which wraps gdalwarp), and save a new file. This changes the stored coordinates and writes the new CRS.

The single most common mistake is using "Set Layer CRS" to try to move a misplaced layer. If a UTM layer is wrongly tagged as 4326 and sits in the wrong place, the fix is to assign its true source CRS (UTM), after which OTF puts it right — not to assign 4326 and reproject from a false starting point.

Project CRS — choose for the task. For interactive viewing, match it to your area so the canvas distortion is small. For a deliverable, set it to the CRS you want measurements reported in.

Processing outputs need attention

A QGIS Processing algorithm's output CRS is not uniform across tools. Some inherit the input layer's CRS, some adopt the project CRS, and many (clip, buffer, reproject, raster terrain tools) expose an explicit Target CRS parameter. Never assume. Before running a buffer or terrain calculation, check the algorithm's parameters, and afterward check the output layer's CRS in its properties. Terrain analysis is the highest-stakes case: slope and aspect must be computed from a DEM in a projected, metric CRS, or the gradient mixes degrees and metres.

A short diagnostic workflow

  1. Inventory. For every layer, read its declared CRS in the layer properties before changing anything.
  2. Separate missing from wrong. No CRS = assign the true one. Wrong CRS but correct-looking position = leave it. Wrong CRS and wrong position = assign the real source CRS.
  3. Reproject analytical layers into a metric projected CRS suited to the extent and the measurement (UTM zone, national grid, or equal-area for area work).
  4. Check units and area of use. Confirm horizontal units (and vertical units if elevation is involved) and that your CRS's valid area covers the project; using a CRS outside its area of use degrades accuracy.
  5. Control-check. Compare against a trusted reference layer for position, and measure a known distance or area to validate the metric result.
  6. Document source CRS, processing CRS, export CRS, and any datum transformation chosen.

Validation before you trust the map

  • Verify exported files carry the CRS you intended — open the output's properties or run gdalinfo / ogrinfo; exports do not silently inherit the project CRS.
  • Measure a known control distance; if it is off by a consistent ratio, suspect a projection (e.g. Web Mercator scale) rather than the data.
  • For area, use the geodesic/ellipsoidal option or a projected CRS, never raw degrees.
  • When a datum transformation is involved (e.g. NAD27↔NAD83, or local↔WGS84), confirm QGIS used the transformation you expect, not a default that can shift positions by metres.

Bathyl perspective

We treat the coordinate chain as something a reviewer must be able to audit, not a hidden default. A map that aligns on screen proves only that OTF reprojection works; trust comes from knowing, and recording, which CRS each measurement and export actually ran in. Keeping layer CRS, project CRS, processing CRS, and export CRS as four explicit decisions is what keeps a deliverable defensible.

Related reading

Sources