Short answer

Web Mercator (EPSG:3857) is the projection behind almost every slippy basemap — Google, Bing, OpenStreetMap tiles. It is excellent at exactly one job: serving square tiles that line up at every zoom level. It is a poor choice for measurement because it is a conformal cylindrical projection whose scale factor grows as 1/cos(latitude). Move away from the equator and everything stretches: at 45 deg latitude linear scale is ~1.41x, at 60 deg it is 2x, at 70 deg roughly 2.9x. Area, being scale squared, is inflated ~2x at 45 deg, ~4x at 60 deg, and ~8.5x at 70 deg.

So a "10 km" line drawn and measured in EPSG:3857 at 60 deg north is really about 5 km on the ground, and a polygon's reported area can be several times its true size. Reproject analytical layers into a projected CRS suited to your task and extent before measuring. Web Mercator is for tiles, not for truth.

Why the distortion is built in

Mercator is conformal: it preserves local angles and shapes, which is why it looks "right" and why navigation historically loved it (a constant compass bearing is a straight line). The price of conformality on a cylinder is that the map must stretch north–south by the same factor it stretches east–west, and that factor is sec(latitude) = 1/cos(latitude). Near the poles cos(latitude) approaches 0, so the stretch approaches infinity — which is why Web Mercator is clipped at about ±85.06 deg and why Greenland looks the size of Africa.

Web Mercator adds a second sin: it projects the ellipsoidal WGS84 latitude/longitude as if the Earth were a sphere. This "spherical-on-ellipsoid" shortcut keeps the tile maths simple but introduces a northing error that grows with latitude (up to ~20 km at high latitudes versus a true ellipsoidal Mercator). EPSG originally refused to issue a code for it; the now-standard EPSG:3857 carries the formal name "WGS 84 / Pseudo-Mercator" precisely to flag that it is not a rigorous projection.

The upshot: in EPSG:3857, one map metre does not equal one ground metre, the ratio changes continuously with latitude, and there is an additional datum-model approximation on top. None of that matters for a tile; all of it matters for a buffer, a length, or an area.

What "right" looks like instead

Choose the projected CRS by what you are measuring and how big the area is:

  • Local distance and buffers (single zone): the appropriate UTM zone (EPSG:326xx / 327xx) or a national grid — e.g. a State Plane zone (US), the British National Grid (EPSG:27700), or a national Lambert. Scale error is well under 0.1% across the zone.
  • Area comparison across a wide region: an equal-area projection — an Albers Equal Area Conic for a mid-latitude country, a Lambert Azimuthal Equal Area for a continent (EPSG:3035 is the standard ETRS89-LAEA for Europe). Conformal projections like Mercator and UTM are not equal-area, so do not use them when relative areas must be comparable.
  • Geodesic measurement on the ellipsoid: when a single planar CRS will not cover the extent, measure geodesically (QGIS measures geodesically by default; PostGIS geography type, ST_DistanceSphere, or ST_Area(geography)).

Worked example: the same line, three ways

A pipeline segment runs across southern Norway, stored in line.gpkg as EPSG:4326, centroid near 60 deg N.

# WRONG: planar length in Web Mercator
ogr2ogr -t_srs EPSG:3857 line_3857.gpkg line.gpkg
# measuring this geometry's planar length overstates ground length ~2x at 60 deg N

# RIGHT: reproject to UTM zone 32N (metres) and measure there
ogr2ogr -t_srs EPSG:32632 line_32632.gpkg line.gpkg

In PostGIS the contrast is explicit:

SELECT
  ST_Length(ST_Transform(geom, 3857))  AS len_webmerc_m,   -- inflated
  ST_Length(ST_Transform(geom, 32632)) AS len_utm_m,       -- correct planar
  ST_Length(geom::geography)           AS len_geodesic_m;  -- correct ellipsoidal

At 60 deg latitude len_webmerc_m comes out roughly double len_utm_m and len_geodesic_m, which agree closely with each other. That factor-of-two is not a rounding issue — it is the 1/cos(60 deg) = 2 scale factor doing exactly what the projection is designed to do.

How big is the error, by latitude

Because the linear scale factor in Web Mercator is exactly sec(latitude), you can predict the error before measuring. The table below gives the linear scale (applied to distances) and the area scale (its square) relative to true ground:

  • 0 deg (equator): linear 1.00, area 1.00 — effectively correct.
  • 23.5 deg (tropics): linear ~1.09, area ~1.19 — ~9% long, ~19% oversized.
  • 45 deg (mid-latitude): linear ~1.41, area ~2.0 — distances overstated ~41%, areas doubled.
  • 60 deg (e.g. Oslo, Anchorage): linear 2.0, area 4.0.
  • 70 deg (high Arctic): linear ~2.9, area ~8.5.

Two further points: the scale varies within a single feature that spans latitude, so a long north–south line has no single correction factor; and the spherical-vs-ellipsoidal approximation adds its own latitude-dependent northing offset on top. There is no constant "fudge factor" you can apply after the fact — the only correct fix is to compute in an appropriate CRS in the first place.

On-the-fly reprojection does not make data measurable

OTF reprojection (QGIS project CRS, ArcGIS data frame) reprojects layers for display so they overlay correctly. It does not change the analytical result. In QGIS, the measure tool and area/length expressions follow the project's measurement/ellipsoid settings, while many Processing algorithms compute in the layer's CRS. So if your layer is in EPSG:3857 and a tool measures in layer units, you get inflated numbers regardless of how nicely things line up on screen. The reliable pattern is to reproject the layer to a metric CRS first, then run the analysis, then reproject the output back to 4326/3857 only if you need it for web display.

Common pitfalls and why they happen

  • Measuring in 3857 because the basemap is in 3857. The basemap's CRS is irrelevant to analysis; it is there to render tiles. Add a metric working layer and analyse there.
  • Using 3857 for area statistics across latitudes. Even small latitude ranges bias relative areas because the scale changes continuously. Use an equal-area CRS.
  • Assuming UTM is "equal area." It is conformal, fine for distance within a zone, but not for cross-region area comparison. Match the projection property to the metric.
  • Trusting OTF alignment as analytical correctness. Display alignment and measurement validity are independent. Reproject the data, not just the view.
  • Ignoring the spherical-vs-ellipsoidal shift. Coordinates round-tripped 4326↔3857 carry the pseudo-Mercator approximation; do not treat 3857 northings as survey-grade. Keep the ellipsoidal 4326 copy authoritative.

QA before you trust the output

  • Confirm each analytical layer's CRS is projected and metric (ogrinfo -al -so, Layer Properties) before measuring — eastings/northings in metres, not degrees, and not pseudo-Mercator.
  • Cross-check one measurement against a geodesic computation (QGIS geodesic measure or PostGIS geography); they should agree to within a fraction of a percent for a local extent.
  • For areas, verify the CRS is equal-area if you compare polygons across the region.
  • Re-measure a known control distance; in a correct CRS it matches ground truth, in 3857 it will be inflated by sec(latitude).
  • Document source CRS, analysis CRS, and output CRS so the measurement chain is reproducible.

Bathyl perspective

We use Web Mercator only as a delivery layer — the basemap under a published viewer — never as the CRS anything is measured in. Every distance, buffer, and area in a Bathyl deliverable is computed in an explicit projected (and, for area work, equal-area) CRS recorded in the project metadata, with at least one geodesic cross-check, so a reviewer can confirm the number rather than inherit a sec(latitude) error.

Related reading

Sources