WGS 84 and Web Mercator are the two coordinate reference systems most GIS users meet first, and they are often treated as interchangeable because both are based on the same datum. They are not interchangeable: one describes positions on the globe in degrees, the other flattens those positions onto a square map in metres. This article covers what each one is, where the differences appear in practice, and which to use for storage, display and measurement.

WGS84 vs Web Mercator: What Is the Difference?

WGS 84 (EPSG:4326) is a geographic coordinate system: latitude and longitude on an ellipsoid, the same values a GNSS receiver produces. Web Mercator (EPSG:3857) is a projected coordinate system: the same positions converted into metres on a flat square that can be divided into map tiles. WGS 84 answers where something is on the Earth, Web Mercator answers where to draw it on a screen.

WGS84 vs Web Mercator

What Is WGS 84?

WGS 84 is the global geodetic reference system used by GPS. It defines an ellipsoid approximating the shape of the Earth and a reference frame that fixes the origin and orientation of the coordinate axes. Positions are expressed as latitude and longitude in degrees, optionally with ellipsoidal height.

The reference frame is maintained and periodically refined: the current realization, WGS 84 (G2296), took effect in 2024 and agrees with ITRF2020 at the level of a couple of centimetres. For everyday GIS this is invisible, but it matters for surveying and any work where positions are compared across years, because tectonic motion moves points by centimetres per year.

OSM in WGS 84 projection

What Is Web Mercator?

Web Mercator is a variant of the Mercator projection created for online maps. Its distinguishing feature is a shortcut: latitude and longitude measured on the WGS 84 ellipsoid are fed into the simpler spherical Mercator formulas. The result is not a rigorous projection, which is why the EPSG registry initially declined to issue a code for it and eventually named it Pseudo-Mercator.

Before EPSG:3857 was settled on, the same system circulated under several identifiers, including the unofficial 900913, the deprecated EPSG:3785 and Esri's 102100 and 102113. These still appear in older projects and configuration files, and although they describe effectively the same thing, only 3857 should be used in new work.

OSM in Web Mercator projection

Why Web Mercator Won on the Web

The projection has one property that made it ideal for slippy maps: the world becomes a square that can be halved recursively, so every zoom level is a clean grid of tiles and tile coordinates are simple arithmetic rather than a geodetic computation. Cutting the map at about 85.06° north and south is precisely what makes the extent square.

Conformality helps too. Because angles are preserved locally, shapes of buildings, road intersections and coastlines look correct at street level, and north is always up. For a navigation map viewed at city scale, this is exactly the right compromise.

Distortion: Scale and Area

The price is scale that changes with latitude. The linear scale factor is one divided by the cosine of latitude, so at 45° everything is stretched by about 1.41, at 60° by 2, and at 70° by roughly 2.9. Area is distorted by the square of that factor, which is why Greenland appears comparable to Africa when it is roughly fourteen times smaller.

This distortion is not a defect for display: it is the mechanism that keeps shapes locally correct. The problem begins when a measurement or an analysis is run on the projected coordinates as if a metre on the map were a metre on the ground.

The Ellipsoid Shortcut

Beyond the projection distortion, Web Mercator carries a second, less obvious error. Applying spherical formulas to ellipsoidal latitudes displaces positions along the north-south axis: compared with the rigorous ellipsoidal Mercator (EPSG:3395), the EPSG registry cites a scale error of about 0.7 per cent and northing differences of up to 43 km on the map, corresponding to roughly 21 km on the ground.

Because the same distortion applies to basemaps and to overlaid data, layers still line up on screen and nothing looks wrong. The error surfaces when coordinates are exported and used as real positions, which is why NGA issued an advisory warning that Web Mercator can produce location errors of up to 40 km and should not be used for navigation or other mission-critical work.

Measuring Distances and Areas

Neither system is a good choice for direct measurement. Degrees are not a unit of length: one degree of latitude is about 111 km everywhere, while one degree of longitude shrinks from 111 km at the equator to zero at the poles, so a buffer specified in degrees is an ellipse of varying size, not a circle. Web Mercator gives metres, but metres whose meaning changes with latitude.

The correct approach is to pick a projection for the measurement: a UTM zone or a national grid for local distances and buffers, and an equal-area projection such as a regional Albers or Lambert azimuthal for statistics by area. Modern GIS can also compute geodesic lengths and areas directly on the ellipsoid, which QGIS and ArcGIS Pro do when the ellipsoid setting is configured, and this is the safest option for data spanning large regions.

Axis Order and Other Practical Traps

EPSG defines the axis order of 4326 as latitude first, then longitude, while GeoJSON, most web APIs and many libraries use longitude first. When the two conventions meet, points appear in the wrong hemisphere or land in the ocean south of Ghana, where coordinates swapped around zero end up. Checking the order is the first thing to do when data appears in an unexpected place.

A second trap is a missing or wrong CRS declaration. Coordinates in metres interpreted as degrees collapse into a tiny cluster near the origin, and degrees interpreted as metres put the whole dataset within a few hundred metres of the equator. Both are immediately visible on a map, but only if a basemap is loaded for reference.

Which One to Store Data In

For storage and exchange, WGS 84 is the sensible default: it is what GNSS produces, what web APIs expect, what GeoJSON requires and what every tool can reproject from. Web Mercator is a display format, so storing data in it means baking a projection choice into the data and rounding coordinates to metres on a distorted grid.

The exception is pre-rendered content. Tile caches, tiled basemaps and vector tiles are generated in Web Mercator because the tiling scheme is defined in it, and reprojecting them later would mean regenerating the whole pyramid.

Common Mistakes

The most common mistake is measuring in Web Mercator by accident. A length or area computed on projected coordinates at the latitude of Northern Europe can be off by a factor of two in distance and four in area, and nothing in the result signals the problem.

The second is assuming that on-the-fly reprojection makes measurement safe. Displaying a layer in a different CRS does not change how the calculation is done: what matters is the CRS or the ellipsoid setting used by the measurement tool.

The third is treating 4326 as a projection in analysis. Running a spatial join, a buffer or a nearest-neighbour search on degrees produces results that are correct in the tropics and increasingly wrong toward the poles, because the underlying geometry code assumes a flat plane.

FAQs

Is WGS 84 a projection?

No. It is a datum and a geographic coordinate system. A projection converts its latitude and longitude into a flat coordinate system, and Web Mercator, UTM and Lambert Conformal Conic are all examples of doing that.

Why do QGIS and my tile server disagree about area?

Most likely because one figure is planar area in Web Mercator and the other is geodesic area on the ellipsoid. Checking which ellipsoid and CRS the measurement tool is using normally explains the difference.

Can distances measured in Web Mercator be corrected?

Approximately, by multiplying by the cosine of latitude, which works for short distances at a known latitude. For anything longer or spanning several latitudes, a proper projected CRS or a geodesic calculation is the right answer.

What is the difference between EPSG:3857 and EPSG:3395?

EPSG:3395 is Mercator computed rigorously on the WGS 84 ellipsoid, while 3857 uses spherical formulas. The two differ by up to about 43 km in northing on the map, and 3395 is not used for web tiles.

Should data be reprojected to Web Mercator before publishing a web map?

Not necessarily. Most web services and clients reproject on the fly, and modern libraries also support other tiling schemes. Data should be published in the CRS that fits the task, with Web Mercator used for the rendered tiles.

Key Takeaways

WGS 84 and Web Mercator sit at different stages of the same pipeline. WGS 84 records where things are, on an ellipsoid, in degrees, in the frame that GNSS provides. Web Mercator turns those positions into a square grid of tiles that is fast to serve and looks right on a screen, at the cost of scale that grows with latitude and a north-south displacement inherited from its spherical formulas.

The practical rule is to store and exchange in WGS 84, display in Web Mercator, and measure in neither. Choosing a suitable projected CRS for the area of interest, or asking the software for geodesic values, avoids the whole class of errors these two systems generate when they are used for a job they were not designed for.