Web Mercator (EPSG:3857): The Projection of Every Web Map

Open any web map — Google Maps, OpenStreetMap, Apple Maps, Mapbox- based maps, the Coordinately homepage — and you are looking at Web Mercator. Since Google Maps launched in 2005 with the projection baked in, almost every commercial and open-source slippy-map provider has followed. The choice has practical consequences for tile servers, for accuracy near the poles, and for any code that crosses between display and computation. This article unpacks what Web Mercator is, how it differs from classical Mercator, and when it is the right (or wrong) projection to use.

The pillar on map projections covers projections in general; the classical Mercator article covers the ellipsoidal 1569 projection Web Mercator is based on. This article focuses specifically on the Web variant and its design trade-offs.

The math

Web Mercator uses the spherical Mercator formulas applied to a sphere of radius R = 6,378,137 m — the WGS 84 ellipsoid's semi-major axis. The flattening parameter f = 1/298.257223563 is ignored.

Forward (latitude / longitude → easting / northing):

x = R · λ                                      (longitude in radians)
y = R · ln(tan(π/4 + φ/2))                     (latitude in radians)

Inverse:

λ = x / R
φ = 2 · arctan(exp(y / R)) − π/2

The simplicity is the point. Classical ellipsoidal Mercator (EPSG:3395) uses a more complex y-formula incorporating the ellipsoid's eccentricity e. Web Mercator drops that correction and treats the Earth as a sphere — a deliberate approximation that simplifies both the math and the tile-server arithmetic.

The result is a projection that's technically not perfectly conformal on the WGS 84 ellipsoid (the conformality assumption applies to a sphere) but is conformal enough for visual display. The non-conformality is small: angles deviate from the spherical ideal by tenths of a percent at high latitudes, undetectable at visual display zoom levels.

EPSG:3857

EPSG:3857 is the canonical identifier for Web Mercator — “WGS 84 / Pseudo-Mercator” in EPSG's own naming. The “Pseudo” prefix is the EPSG registry's acknowledgment that the projection isn't a proper ellipsoidal Mercator. The code was added to the registry in 2008, several years after the projection was already widely deployed (Google launched it in 2005). The history of the code is a small curiosity: before EPSG:3857 was assigned, the projection circulated under several unofficial codes:

• EPSG:900913 — “Google” spelled in calculator-upside-down digits. Used by OpenLayers and some early GIS libraries.
• EPSG:3785 — an earlier provisional EPSG code, since deprecated.
• EPSG:3857 — the current official code.

Modern systems uniformly use EPSG:3857. Software encountering 900913 or 3785 should treat them as aliases for 3857.

Slippy-map tile arithmetic

A slippy map is a web map composed of pre-rendered raster or vector tiles, fetched on demand as the user pans and zooms. Each tile is identified by three integers:

• Z — zoom level. At zoom 0, the entire world is a single 256 × 256 pixel tile. At each subsequent zoom level, the linear resolution doubles: zoom 1 is 2 × 2 = 4 tiles, zoom 2 is 4 × 4 = 16 tiles, zoom 18 is 2^18 × 2^18 ≈ 70 billion tiles.
• X — tile column, from 0 (west) to 2^Z − 1 (east).
• Y — tile row, from 0 (north) to 2^Z − 1 (south). (Note: some systems use bottom-up row numbering; the OpenStreetMap / Google standard is top-down.)

The OpenStreetMap slippy-map tilenames specification documents the canonical formulas. Given latitude φ and longitude λ, the (X, Y, Z) tile addresses are:

n = 2^Z
X = floor( (λ + 180) / 360 · n )
Y = floor( (1 − ln(tan(φ) + sec(φ)) / π) / 2 · n )

Both formulas are pure arithmetic — no ellipsoid corrections, no iterative computation. A tile-server can resolve a /Z/X/Y.png request to a pre-rendered tile in microseconds. This trivial arithmetic is the engineering reason Web Mercator beat all competing projections for slippy-map use.

A worked example

Convert the Empire State Building at (40.7484°N, 73.9857°W) from EPSG:4326 (geographic WGS 84) to EPSG:3857 (Web Mercator):

Inputs:
  φ = 40.7484° = 40.7484 × π/180 = 0.7112 rad
  λ = −73.9857° = −73.9857 × π/180 = −1.2912 rad
  R = 6,378,137 m

Forward formulas:
  x = R · λ
    = 6,378,137 · (−1.2912)
    = −8,235,906 m

  y = R · ln(tan(π/4 + φ/2))
    = 6,378,137 · ln(tan(0.7854 + 0.3556))
    = 6,378,137 · ln(tan(1.1410))
    = 6,378,137 · ln(2.1882)
    = 6,378,137 · 0.7831
    = 4,994,866 m

In Web Mercator coordinates: (-8,235,906 E, 4,994,866 N). The homepage tool emits these numbers directly when you click the Empire State Building's location. For comparison, classical ellipsoidal Mercator (EPSG:3395) for the same point yields roughly (-8,235,906 E, 4,969,866 N) — same easting (longitude is treated identically), but a northing offset of ~25 km. That offset is the sphere-not-ellipsoid difference at 40°N, accumulated through the ln(tan) integration.

The PROJ library — used inside every modern GIS — handles conversions between EPSG:4326 and EPSG:3857 in a single function call, performing the arithmetic above behind the scenes.

The ±85.0511° cutoff

Web Mercator is defined only between latitudes ±85.0511287798°. The exact value is arctan(sinh(π)) ≈ 85.05113°. Beyond these latitudes, the projection is undefined: the y-coordinate would exceed the x-coordinate's antimeridian extent, breaking the square-tile assumption.

The geometric meaning: at exactly ±85.0511°, the projection's y-coordinate equals its x-coordinate at the antimeridian. Truncating at this latitude produces a square world map that tiles cleanly into 2^N × 2^N grids. A wider truncation (e.g., ±88°) would produce a tall-rectangle map that doesn't tile evenly; a narrower one would discard usable area.

The polar regions north of 85.0511°N (most of the Arctic Ocean ice pack) and south of 85.0511°S (much of Antarctica's interior) are invisible on Web Mercator. For polar work, slippy-map providers either omit polar coverage entirely (Google, Mapbox) or provide specialised polar tiles using Universal Polar Stereographic (the Norwegian Polar Institute does this for Svalbard / Arctic Ocean mapping).

Differences from classical Mercator

Web Mercator's sphere-not-ellipsoid approximation produces small coordinate offsets compared with classical Mercator. The offset grows with latitude:

| Latitude | Approximate offset between WGS 84 Mercator (3395) and Web Mercator (3857) | | -------- | --- | | 0° (equator) | 0 m | | 30° | ~9 m | | 45° | ~15 m | | 60° | ~35 m | | 70° | ~100 m | | 80° | ~280 m | | 85° | ~700 m |

For surveying, infrastructure work, or any sub-metre application, classical Mercator (EPSG:3395) or a proper UTM is the right projection. For slippy-map display at any zoom level a user looks at, the offset is below the pixel size of the rendered tile — invisible.

This is why the formal EPSG name is “Pseudo-Mercator”: the projection is Mercator in shape and behaviour but not in the strict geodetic sense. The naming flags the approximation explicitly so software handling sub-metre work knows to choose EPSG:3395 instead.

When Web Mercator is the right choice

• Slippy-map tile rendering. The single biggest use case. Every major web mapping provider, every Mapbox-style API, every OpenLayers/Leaflet/MapLibre application. The tile arithmetic and the conformal-enough shape make Web Mercator the natural choice.
• Web-based interactive maps. Where the user pans, zooms, and views a small region at a time, Web Mercator's area distortion at high latitudes is invisible (the user can't see Greenland and Africa simultaneously at typical zoom levels).
• Display layers in GIS dashboards. The base map under thematic overlays is typically Web Mercator.
• Where the inputs are geographic and the outputs are pixel positions. The transformation is fast and well-understood.

When Web Mercator is the wrong choice

• Surveying and engineering. Use UTM, State Plane, or a national grid. Web Mercator's spherical approximation costs metres of accuracy at high latitudes.
• Thematic mapping showing area-weighted data. Use an equal- area projection (Mollweide, Eckert IV, Albers). Web Mercator's polar inflation makes Greenland look the size of Africa, which is misleading for area-based statistics.
• Polar work. Use UPS for polar caps; Web Mercator cuts off at ±85.0511° and distorts severely above 60°.
• Distance measurement. Compute geodesic distance directly from the geographic coordinates (Vincenty on WGS 84), not by subtracting projected coordinates. The /tools/distance-calculator tool uses Vincenty regardless of the display projection.
• Server-to-server geographic data exchange. Use WGS 84 geographic (EPSG:4326) — the universal exchange currency. Reproject to Web Mercator only at the display boundary.

Common misconceptions

“Web Mercator is the same as Mercator.” Closely related but technically different. Classical ellipsoidal Mercator (EPSG:3395) uses ellipsoidal formulas; Web Mercator (EPSG:3857) uses spherical formulas on a sphere of the WGS 84 ellipsoid's semi-major-axis radius. The difference is small at low latitudes and substantial near the poles.

“Web Mercator is conformal.” Approximately conformal in the sense that angles are preserved on the spherical model — but the spherical model itself is an approximation of the ellipsoid. So Web Mercator is not strictly conformal on the WGS 84 ellipsoid. The deviation is small (tenths of a percent at high latitudes) but real. The EPSG registry calls it “Pseudo- Mercator” to flag the approximation.

“Web Mercator was designed to mislead about country sizes.” No — Web Mercator was designed for slippy-map tile arithmetic. The area distortion is an inherited mathematical property of cylindrical conformal projections, the same one classical Mercator has had since 1569. The visual effect (Greenland looks like Africa) is a side-effect of preserving shape, not a design intent.

“You can't make accurate maps in Web Mercator.” You can — accurate to the spherical approximation, which is sub-metre at low latitudes and several-hundred-metres near the poles. Whether that's “accurate enough” depends on the use. For visual display at typical zoom levels: yes. For surveying: no.

“Web Mercator is the same projection across all providers.” Yes. EPSG:3857 is a single global standard. Google, Mapbox, Apple, Bing, OpenStreetMap, MapLibre, OpenLayers, Leaflet, and every other slippy-map system that follows the OGC Web Map Tile Service or similar conventions uses identical coordinate formulas and tile addressing. Aside from styling and the specific tile data, the projection is uniform.