What is on-the-fly reprojection in QGIS?

QGIS transforms each layer's coordinates from its own CRS into the project CRS at draw time, so layers in different coordinate systems display together correctly. It is a display-time operation; the files on disk are unchanged.

Does on-the-fly reprojection change my data on disk?

No. It only affects how layers are drawn and how the map canvas reports coordinates. To create a new file in a different CRS you must export with Save Features As or run a reprojection tool like ogr2ogr or the Reproject Layer algorithm.

Why are my measurements wrong even though layers line up?

On-the-fly reprojection aligns the picture but does not change which CRS your analysis tools read. Geoprocessing on a geographic CRS (degrees) produces distances and areas in degrees, and some tools compute on raw layer coordinates regardless of the project CRS.

When should I permanently reproject a layer instead?

Reproject to a suitable projected CRS before any distance, area, buffer, or terrain analysis, and before delivering data to a system that does not handle on-the-fly transforms. Display alignment alone does not make a layer fit for measurement.

On-the-Fly Reprojection in QGIS: What It Does

Short answer

On-the-fly (OTF) reprojection is how QGIS draws layers that are stored in different coordinate reference systems on the same map. Each layer keeps its own CRS on disk; at draw time QGIS transforms its coordinates into the project CRS so everything overlays correctly. Crucially, this is a display operation — it changes nothing in the source files, and it does not guarantee that distance, area, or terrain calculations are correct. OTF makes the picture line up; it does not make every layer fit for measurement.

Two CRS settings, and which one wins

There are two distinct CRS concepts in any QGIS project, and confusing them is the root of most reprojection trouble:

Layer CRS — the coordinate system the layer's data is actually stored in. View it in Layer Properties ▸ Information, or in the Browser. This is a property of the data.
Project CRS — the coordinate system the map canvas is rendered in, set in the bottom-right of the status bar or in Project ▸ Properties ▸ CRS. This is a property of the view.

OTF reprojection is the bridge between them: for every layer whose CRS differs from the project CRS, QGIS applies a coordinate transform pipeline at render time. Since QGIS 3.0, OTF is always on and cannot be disabled — the old "enable OTF" checkbox is gone. This is why a WGS84 layer (EPSG:4326) and a UTM zone 30N layer (EPSG:32630) will draw on top of each other without any manual step.

What OTF does not do

Because it is a render-time transform, OTF leaves three things unchanged:

The files on disk. A layer in EPSG:27700 stays in EPSG:27700 no matter what the project CRS is. Nothing is written.
The coordinates a processing tool reads. Many Processing algorithms operate on the layer's native coordinates, not the project CRS. If you buffer a layer that is stored in degrees, you get a buffer in degrees, regardless of how the map looks. The geometry-calculator field expressions ($area, $length) are CRS-aware via the project's ellipsoid setting, but raw geometric tools generally are not.
Fitness for analysis. Web Mercator (EPSG:3857) is fine for a slippy basemap but distorts area badly away from the equator; measuring a polygon's area in a Web Mercator project will be wrong even though it displays perfectly.

This is the trap: the map looks right, so the analysis is assumed right. Alignment is a necessary condition, not a sufficient one.

Datum transforms hide inside OTF

When two CRSs are based on different datums (say, transforming between an old national datum and WGS84), the transform is not a simple formula — it needs a datum transformation, often a grid shift. QGIS uses PROJ to choose one. Under Settings ▸ Options ▸ Coordinate Reference System ▸ Datum Transformations, you can see and pin which transformation is applied, and QGIS warns when multiple candidates exist with different accuracies. If the high-accuracy grid (e.g. an NTv2 .gsb file) is not installed, PROJ falls back to a ballpark transform that can be off by several metres. For most display work this is invisible; for survey-grade overlay it is not, so check the chosen transform when accuracy matters.

Worked example: a layer in the wrong place

Suppose a contractor's shapefile of borehole points plots in the Atlantic Ocean instead of on your UTM project area. Two very different problems produce the same symptom, and the fix differs:

Case A — wrong/missing CRS metadata. The .prj file is missing or says EPSG:4326, but the X/Y values are actually eastings/northings in EPSG:32630. The data is fine; the label is wrong. Fix by assigning the correct CRS, not reprojecting: Layer Properties ▸ Source ▸ Set the layer CRS to EPSG:32630, or ogr2ogr -a_srs EPSG:32630. Do not run a reprojection — that would transform coordinates that are already correct and move them again.

Case B — correct metadata, you just want a different CRS. The layer is honestly EPSG:4326 and you want a projected copy for analysis. Here you reproject: Processing ▸ Vector general ▸ Reproject Layer, target EPSG:32630, save to a new file. OTF handled the display; this step produces real projected coordinates on disk.

The deciding question is always: are the stored coordinates already correct? If yes, assign. If no — they are correct in a different CRS and you want to move them — reproject.

When to permanently reproject

Rely on OTF for viewing and quick overlay. Reproject to a suitable projected CRS (UTM zone, a national grid, or an equal-area projection) before:

Distance, area, perimeter, or buffer operations.
Terrain analysis — slope, aspect, hillshade, viewshed — which assume planar coordinates in linear units.
Nearest-neighbour, density, and most spatial-statistics tools.
Delivering to a system or library that does not do OTF (some web pipelines, some legacy software).

Choose the CRS for the job: a single UTM zone for a project a few hundred kilometres wide; an Albers or Lambert equal-area projection for area statistics over a large region; the relevant national grid for cadastral or engineering work.

Validation

Visual check. Add a trusted reference layer (an OSM basemap via the QuickMapServices/XYZ tiles, or a known administrative boundary) and confirm your data sits where it should.
Measurement check. Use the Measure tool, which respects the project ellipsoid, and compare a known distance (a road segment of surveyed length, a grid square) against the measured value.
CRS audit. Open Layer Properties ▸ Information for every layer and confirm the declared CRS is the real one. Inconsistent CRS across layers is the warning sign.
Coordinate readout. Hover over a known point and read the canvas coordinate; it should match the expected value in the project CRS.

Common pitfalls and why they happen

Measuring area in a Web Mercator project. EPSG:3857 preserves shape locally but inflates area with latitude, so areas read far too large in mid-to-high latitudes. It happens because the basemap forced the project into 3857 and nobody changed it back.
Assigning a CRS to "fix" a misplaced layer that actually has correct metadata. This double-transforms and moves good data. It happens when "assign" and "reproject" are treated as the same button.
Buffering a layer stored in degrees. A 100-unit buffer becomes 100 degrees — roughly 11,000 km. It happens because OTF made the layer look projected while the tool read the native geographic coordinates.
Ignoring vertical units. Elevation in feet under a horizontal CRS in metres breaks slope and volume calculations. OTF only handles horizontal CRS, never the vertical component.

Bathyl perspective

We treat OTF as a convenience for the eyes and never as a substitute for an explicit CRS decision. Every analytical layer in a deliverable is reprojected to a documented projected CRS chosen for the measurement task, and the source CRS, processing CRS, and datum transformation are recorded so another analyst can reproduce the numbers, not just the picture.

On-the-Fly Reprojection in QGIS