Web Mercator Latitude Limits and Distortion

Web Mercator cuts off at ±85.0511287798° because that is the latitude at which the projected world becomes exactly square, and a square world is what makes the quadtree tiling scheme work. Everything above that line has no tile. Everything below it is stretched by a factor that grows without bound as you approach the pole, and that stretch changes what a zoom level means depending on where you are.

When to Use This

Three situations force this into view: a dataset with features above 85° that vanish from the tileset, an area or length calculation done in projected coordinates that comes out wrong, and a zoom-level plan derived from equatorial ground resolution that turns out to be far too coarse at high latitude.

Specification Detail

The forward projection is:

x = R × λ
y = R × ln(tan(π/4 + φ/2))

As φ approaches ±90°, y approaches infinity. Choosing φ so that y = ±R × π — the same magnitude as the x range at the antimeridian — gives the square world and the 85.0511° cut-off.

What This Means for a Tile Pipeline

Ground resolution per zoom is latitude-dependent. The familiar table of metres per pixel — 156543 at z0, halving each level — is the equatorial figure. At 60° north, every value is halved again; a z14 tile in Oslo covers about half the ground of a z14 tile in Nairobi.

The practical consequence lands on zoom planning. A maximum zoom calculation that measures feature density per square kilometre and converts to features per tile must use the tile’s local ground area, not the equatorial one. Using the equatorial figure for a Scandinavian city overestimates the features per tile by a factor of four, and produces a max zoom one or two levels deeper than necessary.

Areas computed in projected coordinates are meaningless. A polygon’s area in EPSG:3857 square metres is inflated by 1/cos²(φ). At 60° that is a factor of four; at 85° it is 132. Compute areas in a suitable equal-area projection or on the ellipsoid, never in Web Mercator.

Features above the limit are not in the tileset. They are not dropped by a flag or a filter, they simply have no tile to be in. A dataset of Arctic monitoring stations tiled without comment will silently lose everything above 85.05°.

Production Command

Find features that will not survive tiling, and measure the local ground resolution properly:

import math

MAX_LAT = 85.0511287798

def ground_resolution(latitude: float, zoom: int, tile_px: int = 256) -> float:
    """Metres per pixel at a latitude and zoom."""
    return (156543.03392 * math.cos(math.radians(latitude))) / (2 ** zoom) * (256 / tile_px)


def tile_ground_area_km2(latitude: float, zoom: int) -> float:
    side_m = ground_resolution(latitude, zoom) * 256
    return (side_m / 1000) ** 2


for city, lat in [("Nairobi", -1.29), ("London", 51.5), ("Oslo", 59.9), ("Tromsø", 69.6)]:
    print(f"{city:9s} z14 tile ≈ {tile_ground_area_km2(lat, 14):5.2f} km², "
          f"{ground_resolution(lat, 14):.2f} m/px")

# Nairobi   z14 tile ≈  9.36 km², 11.94 m/px
# London    z14 tile ≈  3.64 km²,  7.44 m/px
# Oslo      z14 tile ≈  2.36 km²,  6.00 m/px
# Tromsø    z14 tile ≈  1.15 km²,  4.18 m/px

# Features that will have no tile at all
ogrinfo -dialect SQLite -sql \
  "SELECT COUNT(*) AS above_limit FROM stations WHERE ST_Y(geometry) > 85.0511" \
  stations.geojson

Interaction Effects

With zoom-level optimisation. Density thresholds must be computed with the local tile area. A single global threshold produces tiles that are over budget at the equator or wastefully deep at high latitude — see zoom level optimization strategies.

With simplification tolerance. Tolerance expressed in ground units suffers the same latitude dependence. Expressing it in tile units — which is what Tippecanoe’s --simplification does — sidesteps the problem entirely, and is one reason that parameterisation is preferable.

With alternative projections. Polar datasets are usually better served by a projection built for them, such as EPSG:3413 for the Arctic, with its own tiling scheme. Vector tiles do not require Web Mercator; the tooling defaults to it, and stepping outside means giving up most of that tooling.

Common Mistakes

Clamping latitude to ±90° in a conversion. Produces a y tile index outside 0..2^z-1, and depending on the code either an exception or a request for a tile that cannot exist.

Using equatorial metres-per-pixel everywhere. The most common version of this error, and it makes every high-latitude zoom decision one or two levels too deep.

Computing area in EPSG:3857. Inflated by up to two orders of magnitude. This appears in choropleth density calculations more often than anywhere else, where it silently exaggerates high-latitude regions.

Assuming the limit is 85°. It is 85.0511287798°. The difference is about six kilometres, which is enough to include or exclude real features on a polar dataset.

FAQ

Why is the limit not exactly 85 degrees?

Because it is derived, not chosen. The value is atan(sinh(π)) expressed in degrees — the latitude at which the projected y extent equals the x extent, making the world square and the quadtree tiling scheme possible.

Can vector tiles cover the poles at all?

Not in Web Mercator. A different projection with its own tiling scheme can, and MapLibre supports custom projections to a limited extent, but the standard tooling — Tippecanoe, PMTiles clients, most tile servers — assumes Web Mercator throughout.

Does the distortion affect tile size?

Indirectly and significantly. A high-latitude tile covers less ground, so it holds fewer features, so it is smaller for the same data density. That is exactly why a max-zoom calculated at the equator is too deep further north.

Is Web Mercator wrong for maps?

It is wrong for measurement and fine for navigation, which is what it was designed for: it preserves angles locally, so shapes look right at any zoom. The failure is treating projected coordinates as measurable ground distances.

Related

• Tile Coordinate Systems & the Slippy Map Grid — the parent topic and the four coordinate systems in play.
• Converting Lat/Lon to Slippy-Map Tile Numbers — the conversion that must clamp at this limit.
• Calculating Optimal Max Zoom for Urban Datasets — where the local tile area belongs in the arithmetic.
• Zoom Level Optimization Strategies — density profiling that must account for latitude.