Short answer

EPSG:4326 and EPSG:3857 are two different coordinate reference systems for the same planet. EPSG:4326 (WGS84) is geographic: it stores longitude and latitude as angles in degrees on the WGS84 ellipsoid. EPSG:3857 (Web Mercator) is projected: it flattens those angles onto a square map in metres, the system every slippy-map basemap (Google, OSM, Mapbox) uses for tiles. They are not interchangeable — one is angular, the other is a heavily distorted planar grid.

The rule that prevents most trouble: store and exchange in 4326, display web tiles in 3857, and measure in neither. Distance, area, and buffer calculations belong in a local projected CRS chosen for your region.

What each system really is

A CRS pins file coordinates to real locations on Earth. The two here differ at every level.

EPSG:4326 uses the WGS84 datum and reports positions as (longitude, latitude) in decimal degrees — the same coordinates GPS produces. It is a geographic system: its units are angles, not lengths. A point is (-1.5, 53.8), not (x metres, y metres). Note the axis-order trap: the EPSG definition is latitude-first, but GeoJSON, most GDAL output, and many tools use longitude-first. Reversed coordinates land your data in the wrong hemisphere.

EPSG:3857 takes WGS84 longitude/latitude and applies a spherical Mercator projection — treating the ellipsoid as a sphere — producing easting/northing in metres spanning roughly ±20,037,508 m. It is built for one job: serving 256×256 tiles in a power-of-two quadtree so basemaps pan and zoom smoothly. It deliberately truncates near ±85.06° latitude to keep the map square.

Why Web Mercator distorts measurement

Mercator is conformal — it preserves shapes and angles locally — but it cannot also preserve area or distance. To keep angles true, it stretches the map increasingly toward the poles. The scale factor is:

k = 1 / cos(latitude)

At the equator k = 1 (true scale). At 45°, k ≈ 1.41. At 60°, k ≈ 2.0 — features are drawn twice their true linear size, so areas are inflated about fourfold. This is why Greenland looks larger than Africa on a Web Mercator world map though Africa is roughly 14 times bigger.

The practical consequence: a length measured in EPSG:3857 metres is not a ground length except near the equator. Run a buffer of "1000 m" or compute an area in 3857 at high latitude and the result is silently and badly wrong. The map looks fine; the numbers are fiction.

Measuring directly in EPSG:4326 is no better — its units are degrees. One degree of latitude is ~111 km everywhere, but one degree of longitude shrinks from ~111 km at the equator to 0 km at the poles (it scales by cos(latitude)). A "0.01 degree" buffer is a different ground distance at every latitude and is not even circular.

When to use each

  • EPSG:4326 — storing and exchanging point/vector data, GPS coordinates, web APIs (GeoJSON mandates it per RFC 7946), and as the lingua franca between systems.
  • EPSG:3857 — display only, when your data must align with XYZ/WMTS basemap tiles. It is a rendering CRS, not an analysis CRS.
  • A local projected CRS — all measurement. UTM zones (e.g. EPSG:32633 for zone 33N) keep distortion under ~1 m per km within the zone; national grids (British National Grid EPSG:27700, etc.) suit single countries; equal-area systems (national Albers/LAEA) suit area statistics over large regions.

The clean architecture is three logical copies of intent: data stored in 4326, an analysis layer reprojected to a local projected CRS, and a display path tiled in 3857 — with documentation stating which is which.

Reproject — don't assign

A constant source of corrupted data is confusing two operations:

  • Reprojecting transforms coordinates from a known source CRS into a target CRS. The numbers change; the real-world location does not. Use this to move from 4326 to 3857 or to UTM.
  • Assigning / defining a CRS only relabels the data without moving it. Correct only when the file's coordinates are already in that CRS but the metadata was missing. Assigning the wrong CRS to "make a layer move" leaves every coordinate physically wrong.

GDAL:

# reproject (correct)
gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 in.tif out_3857.tif
ogr2ogr -t_srs EPSG:32633 out_utm.gpkg in_4326.gpkg   # vector to UTM for measurement

PostGIS — keep transform and label distinct:

-- transform geometry into a measuring CRS, then measure
SELECT ST_Length(ST_Transform(geom, 32633)) AS length_m
FROM pipelines;

-- assign a CRS to data that lacks one but is already lon/lat
UPDATE parcels SET geom = ST_SetSRID(geom, 4326) WHERE ST_SRID(geom) = 0;

ST_Transform reprojects; ST_SetSRID only stamps the SRID. Mixing them up is a frequent, hard-to-spot bug.

Worked example — a buffer that fell ~40% short on the ground

A team buffers facilities by 500 m on a web map at ~55° N, working in EPSG:3857 because that is what the basemap used. At 55°, k = 1/cos(55°) ≈ 1.74, so a "500 m" buffer in Web Mercator metres spans only ~287 m on the ground in linear terms — about 43% short of the intended 500 m — or, depending on how the tool interprets it, the on-screen circle misrepresents the true exclusion zone by a wide margin. Re-running the buffer after ST_Transform(geom, 32630) into the local UTM zone gives a true 500 m radius. The fix is one line; the cost of not noticing is a safety setback that does not hold up.

Datum nuance: WGS84, the spherical assumption, and small shifts

Two subtleties trip up precise work. First, EPSG:3857 projects WGS84 ellipsoidal coordinates as if the Earth were a sphere. That spherical assumption is part of why it is unsuitable for measurement and why it carries the deliberately non-standard "Pseudo-Mercator" label — a true ellipsoidal Mercator would be EPSG:3395, which differs by up to ~20 km in northing at high latitude. Do not assume 3857 and 3395 are the same.

Second, "EPSG:4326" is sometimes treated as if it were a single fixed frame, but WGS84 has been realised in several versions and is now very close to ITRF/ETRS-based frames used by national grids. For most GIS work the differences are sub-metre and ignorable, but for survey-grade or tectonic-rate applications, the datum realisation and epoch matter, and you should drive the transformation through PROJ with an explicit transformation pipeline rather than a bare "4326 to local" guess. PROJ will pick a default operation; for high accuracy, inspect and choose it deliberately (projinfo -s EPSG:4326 -t EPSG:27700 lists candidate operations and their accuracies).

Picking the right UTM zone automatically

Because measurement should happen in a local projected CRS, a recurring task is choosing the UTM zone for an arbitrary area. The zone number is floor((longitude + 180) / 6) + 1, and the EPSG code is 32600 + zone for the northern hemisphere or 32700 + zone for the southern. For a study centred at 11°E, 47°N: zone = floor((11+180)/6)+1 = 32, northern hemisphere, so EPSG:32632. If an area straddles two zones, prefer a single national grid or a custom Transverse Mercator centred on the area rather than splitting the analysis across zones, which would introduce a seam.

Common pitfalls and why they happen

  • Measuring in Web Mercator because it shows metres. The metres are projected, not ground metres; the 1/cos(lat) scale factor inflates them away from the equator. Measure in a local projected CRS.
  • Buffering or computing area in EPSG:4326. Degrees are not metres and longitude degrees shrink with latitude; results are wrong and non-circular. Reproject first.
  • Assigning a CRS to reposition data. It relabels without moving; the coordinates stay physically wrong. Reproject from the true source CRS instead.
  • Axis-order confusion in 4326. Lat/lon vs lon/lat swaps put data in the wrong place. Check your tool's convention.
  • Ignoring vertical units. Horizontal CRS says nothing about elevation units; confirm metres vs feet when DEMs are involved.

Quality checks

  • After reprojecting, overlay against a trusted reference layer and confirm features land where expected.
  • Measure a known distance (a surveyed baseline, a city block) in the analysis CRS and confirm it matches reality.
  • Verify SRIDs explicitly (ST_SRID, gdalinfo, QGIS layer properties) rather than trusting that "it looked aligned".
  • Document source CRS, analysis CRS, display CRS, and any datum transformation in the project notes.

Bathyl perspective

We treat the coordinate chain as part of the deliverable: every layer states its source CRS, the projected CRS used for measurement, and the CRS it is displayed in. A handsome map built on undocumented or Web-Mercator measurements is a liability — making the projection logic auditable is what lets another analyst trust, reproduce, or correct the numbers.

Related reading

Sources