Why is Web Mercator (EPSG:3857) wrong for distance and area?

Web Mercator is a conformal projection that stretches the map north-south by the secant of latitude. At 60 degrees N a feature is drawn roughly twice its true size, so any length or area computed in EPSG:3857 inherits that error. It preserves local angles, not measurements.

Which CRS should I use for analysis instead of Web Mercator?

Use a projected CRS whose distortion is controlled across your project extent: a UTM zone for areas up to about 6 degrees wide, a national grid such as British National Grid (EPSG:27700), or a custom equal-area projection like an Albers or Lambert Azimuthal Equal Area for continental statistics.

How big is the scale error in Web Mercator at high latitudes?

Linear scale factor in Web Mercator equals 1/cos(latitude). It is about 1.15 at 30 degrees, 1.41 at 45 degrees, and 2.0 at 60 degrees. Area scales with the square, so areas at 60 degrees are inflated by roughly four times.

Can I keep a Web Mercator basemap but analyze in a different CRS?

Yes. Set the project or map CRS to EPSG:3857 for display so tiled basemaps align, but reproject vector and raster layers to a suitable projected CRS for any buffer, length, area, or terrain calculation. On-the-fly display reprojection does not change stored coordinates.

CRS for Web Maps vs Analysis: Web Mercator Limits

Short answer

Web Mercator (EPSG:3857) is a display projection. It is the right choice for tiled basemaps and slippy maps because it is conformal (it preserves local angles) and tiles cleanly into a power-of-two quadtree. It is the wrong choice for any measurement, because it inflates north-south scale by the secant of latitude: a feature at 60 degrees north is drawn about twice as long and four times as large as it really is. For distances, areas, buffers, and terrain, reproject your working layers into a projected CRS whose distortion is bounded across the project extent, such as the correct UTM zone or a national grid.

The practical split is simple: display in 3857, compute in something else.

What Web Mercator actually does to your numbers

Mercator is a cylindrical conformal projection. Conformality means it keeps angles and shapes correct locally, which is why it looks natural for navigation and basemaps. The price is that it cannot also preserve area or distance. The linear scale factor k at a given latitude φ is:

k = 1 / cos(φ) = sec(φ)

That gives a clean table you can keep in your head:

Equator (0 degrees): k = 1.00, no distortion
30 degrees: k ≈ 1.15
45 degrees: k ≈ 1.41
60 degrees: k ≈ 2.00
70 degrees: k ≈ 2.92

Because area is two-dimensional, the areal exaggeration is k². At 45 degrees a region measured in EPSG:3857 is roughly twice its true area; at 60 degrees it is roughly four times. This is the mathematical reason Greenland looks the size of Africa on a web map even though Africa is about 14 times larger.

Web Mercator (EPSG:3857) has one extra wrinkle beyond classic Mercator (EPSG:3395): it treats the Earth as a sphere of radius 6378137 m while still using WGS84 ellipsoidal latitude/longitude as input. This "spherical development of ellipsoidal coordinates" introduces a north-south positional error that grows with latitude (up to roughly 20 km near the poles relative to a true ellipsoidal Mercator). For basemap alignment this is invisible; for geodetic work it is another reason not to compute in it.

Why "it displays fine" is a trap

Modern GIS performs on-the-fly (OTF) reprojection. In QGIS the project has a CRS, and every layer is warped into that project CRS at draw time, regardless of its stored CRS. So a UTM layer and a 4326 layer will overlay correctly on a 3857 basemap. Nothing visibly breaks.

The danger is that OTF reprojection only changes what you see, not what is stored. When you run a Processing algorithm, the geometry engine usually operates on each layer's native coordinates (or the project CRS, depending on the algorithm), not on the pretty composited view. If your analytical layer is stored in 4326, a "buffer of 500" is 500 degrees unless you have reprojected first. If it is stored in 3857, a length tool returns 3857 meters, which are not ground meters.

A worked failure: take a polygon in Norway, store it in EPSG:3857, and ask for its area in QGIS using $area in the field calculator with the project CRS left at 3857. At roughly 60 degrees north you will get a number about four times the true ground area. Switch the layer to a UTM zone (Norway spans 32V/33V, EPSG:32632 / 32633) and recompute, and the area collapses to the correct value.

Choosing the right analytical CRS

There is no single "analysis CRS." Pick by extent and by what you need to preserve.

Local to regional (up to ~6 degrees of longitude)

Use the matching UTM zone. UTM is transverse Mercator with a central-meridian scale factor of 0.9996, so distortion stays within about 1 part in 1000 across a zone, units are meters, and EPSG codes are predictable: 326{zone} for the northern hemisphere and 327{zone} for the southern. Example: zone 31N over Belgium and eastern France is EPSG:32631. To find a zone from longitude λ: zone = floor((λ + 180) / 6) + 1.

National extents

Use the official national grid, which is engineered for the country's shape and is what authoritative data already uses:

Great Britain: British National Grid, EPSG:27700 (transverse Mercator on OSGB36)
France: RGF93 Lambert-93, EPSG:2154 (Lambert conic conformal)
Conterminous USA mapping: state plane zones, or a national Albers for statistics

Continental or country-wide statistics

If you need correct areas (density, land-cover totals, susceptibility tallies), use an equal-area projection: Albers Equal Area Conic (good for mid-latitude east-west countries) or Lambert Azimuthal Equal Area (ETRS89-LAEA, EPSG:3035, is the European standard for area statistics). If you need correct distances from a point, use an azimuthal equidistant projection centered on that point.

The rule of thumb: conformal for shape-sensitive overlays and slope/aspect, equal-area for counting and density, equidistant for radial distance.

A clean QGIS / GDAL workflow

Audit native CRS. gdalsrsinfo data.gpkg for rasters, or check Layer Properties > Information. Do not trust the project CRS as a proxy for layer CRS.
Decide the project (display) CRS. Set it to EPSG:3857 if you want web tiles to align. This is purely for viewing.
Reproject analytical layers to your chosen projected CRS before measuring. Vector with ogr2ogr:
```
ogr2ogr -t_srs EPSG:32631 -s_srs EPSG:4326 out_utm.gpkg in.gpkg
```
Raster (DEM, with a vertical-aware resampling for continuous data):
```
gdalwarp -s_srs EPSG:4326 -t_srs EPSG:32631 -r bilinear -tr 30 30 dem_4326.tif dem_utm.tif
```
Measure in the projected layer. Buffers, $area, $length, and the Processing toolbox now return meters and square meters on the ground.
Verify against a known control (see below).
Publish by reprojecting the final product back to 3857 or serving vector tiles, keeping the analytical version archived in its measurement CRS.

In PostGIS the same logic applies. Store geometries in a projected SRID and transform only for delivery: ST_Area(geom) on a 4326 geometry returns square degrees, while ST_Area(geom::geography) or ST_Area(ST_Transform(geom, 32631)) returns square meters.

Common pitfalls and why they happen

Buffering in 4326. The CRS units are degrees, so ST_Buffer(geom, 0.01) is "0.01 degrees," which is ~1.1 km at the equator and shrinks with latitude. It happens because the function signature accepts any number and the units are implicit in the CRS.
Measuring in 3857 because the basemap is in 3857. People conflate display CRS with measurement CRS. The numbers are silently inflated by sec(φ).
Using one UTM zone across a wide project. Beyond ~6 degrees of longitude, distortion at the zone edge climbs. Switch to a national grid or a custom Lambert/Albers.
Ignoring datum shifts. Reprojecting between NAD27 and NAD83, or between local datums and WGS84, can move features tens to hundreds of meters if the transformation (datum operation) is wrong, even when the projection is right.

QA and validation

Scale-factor sanity check. At your project's mean latitude, compute sec(φ). If you measured in 3857 and need a quick truth, divide lengths by roughly sec(φ) and areas by sec²(φ). Better: just remeasure in the projected CRS.
Known control. Measure a feature of known size (a survey baseline, a section line, a 1 km grid square) in your analytical CRS and confirm it returns the expected length within a few parts per thousand.
Cross-check two CRSs. Compute total area in your chosen projected CRS and in EPSG:3035 (or a local equal-area). They should agree closely for area-critical work; a large gap means you measured in a conformal or geographic CRS by mistake.
Round-trip a point. Reproject a coordinate out and back; it should return to within sub-millimeter, confirming the transformation pipeline is valid.

Bathyl perspective

We treat the display CRS and the measurement CRS as two separate decisions that happen to live in the same project. Basemaps stay in 3857 so clients get fast, familiar tiles; every length, area, buffer, and terrain derivative is computed in a projected CRS chosen for the extent, and the choice is recorded next to the result. That separation is cheap to maintain and it removes an entire class of silent errors before they reach a report.

CRS for Web Maps vs Desktop Analysis