Quadkey and Tile Coordinates

Tile coordinates are the operational coordinate system of the zoom-and-pan web map. Where lat/long is the coordinate system for describing locations, and projected coordinates (UTM, State Plane, etc.) are the coordinate system for engineering work, the tile coordinate (z, x, y) is the coordinate system for serving map imagery at scale. The /learn/slippy-map-tiles-explained support covers the operational side of tile-based maps; the /learn/web-mercator-projection support covers the projection underneath. This article focuses on the coordinate-system aspect: how tile coordinates work, how they relate to geographic coordinates, and how the Quadkey encoding makes the hierarchical structure explicit.

The tile coordinate triple

A tile coordinate is a triple (z, x, y) where:

• z is the zoom level, typically an integer from 0 to about 22.
• x is the column index from the left edge of the world (the antimeridian, longitude −180°).
• y is the row index from the top of the projected world (about 85°N).

At zoom level z, the world is divided into 2^z × 2^z tiles. So:

| Zoom level | Tiles | Tile coverage at equator | |---|---|---| | 0 | 1 × 1 = 1 | the entire world | | 1 | 2 × 2 = 4 | ~20,000 km on a side | | 2 | 4 × 4 = 16 | ~10,000 km | | 5 | 32 × 32 = 1,024 | ~1,250 km | | 10 | 1,024 × 1,024 ≈ 1M | ~40 km | | 15 | 32,768 × 32,768 ≈ 1B | ~1.2 km | | 18 | 262,144 × 262,144 ≈ 69B | ~150 m | | 22 | ~17M × 17M ≈ 280 trillion | ~9.5 m |

(Tile coverage shrinks at higher latitudes because of Web Mercator inflation; the equator values are the maximum extent per tile.)

The (z, x, y) triple uniquely identifies one specific 256×256-pixel image — typically a PNG or vector tile of map data — that can be requested from a tile server. The URL convention is https://example.com/{z}/{x}/{y}.png, which is how Google, OpenStreetMap, and most other providers organise their map imagery.

Mapping latitude and longitude to a tile

The conversion from geographic coordinates to tile coordinates is the Web Mercator projection followed by tile-grid indexing. Per the OpenStreetMap Slippy map tilenames documentation, the formulas are:

n = 2^z

x_tile = floor((λ + 180°) / 360° × n)
y_tile = floor((1 − ln(tan(φ) + sec(φ)) / π) / 2 × n)

where φ is the latitude in radians and λ is the longitude in degrees. The natural log term is the Web Mercator y-coordinate normalised to the [0, 1] range; multiplying by n and flooring gives the tile row.

For pixel coordinates within the tile (for sub-tile precision):

x_pixel_within_tile = ((λ + 180°) / 360° × n − x_tile) × 256
y_pixel_within_tile = ((1 − ln(tan(φ) + sec(φ)) / π) / 2 × n − y_tile) × 256

These give a (z, x, y) tile plus a (px, py) pixel coordinate within the tile — enough to render any geographic point on the visible map.

The Web Mercator base

Tile coordinates are inseparable from the Web Mercator projection. Per the EPSG:3857 documentation, Web Mercator is a spherical version of the classical Mercator projection (covered in the /learn/mercator-projection support), applied to a sphere of radius 6,378,137 m. The projection has two properties that make it the universal choice for tile-based maps:

1. The projection is square. A single bounding rectangle that covers the entire projected world is square (rather than the 2:1 wide rectangle of classical Mercator on the ellipsoid). The square fits nicely into a 2^z × 2^z tile grid.
2. The projection is conformal. Local angles are preserved, so street networks, building outlines, and other features retain their shape regardless of where in the world they are displayed.

The trade-off is the well-known area distortion at high latitudes (covered in /learn/why-greenland-looks-huge-on-maps). For tile-based maps the trade-off is accepted; the alternative (equal-area or compromise projections) would not produce a hierarchical tile pyramid that matches the zoom-and-pan UX of a web map.

The ±85° clipping

Web Mercator's projection diverges at the poles — the y coordinate goes to infinity. To produce a finite, square tile grid, the projection is clipped at the latitudes where the projected y-coordinate equals ±π. Solving the projection equation:

ln(tan(φ_max) + sec(φ_max)) = π
=> φ_max ≈ 85.0511287798°

Above 85.05°N or below 85.05°S, no tiles exist. The clipping is invisible for most uses because Antarctica and the highest reaches of northern Greenland are the only landmasses affected — and they are rarely needed on consumer web maps.

For polar-region web mapping, alternative tile schemes built on polar stereographic projections are sometimes used (NASA's NSIDC publishes polar tile sets, for example). But the standard slippy-map convention stops at ±85.05°.

The Quadkey encoding

Microsoft's Bing Maps Tile System documentation introduced the Quadkey as an alternative encoding for tile coordinates. The Quadkey is a base-4 string of length z that encodes the same information as (z, x, y) but in a way that makes the hierarchical structure explicit.

The encoding rule: each character of the Quadkey (0, 1, 2, or 3) identifies which of four child tiles to descend into at that zoom level:

0 = upper-left  (x = 2k,   y = 2k)
1 = upper-right (x = 2k+1, y = 2k)
2 = lower-left  (x = 2k,   y = 2k+1)
3 = lower-right (x = 2k+1, y = 2k+1)

So the Quadkey “02132” identifies a specific zoom-5 tile by saying: start at zoom 0 (one tile covers the world). Descend into the upper-left quadrant (Quadkey character “0”, zoom 1 tile). Then the upper-left again (Quadkey character “2”, zoom 2 tile — wait, “2” is lower-left). Then upper-right (1). Then lower-right (3). Then lower-left (2). Five steps down means zoom 5.

The corresponding (z, x, y) triple can be computed by interleaving the bits of x and y from most-significant to least-significant. For the Quadkey “02132” the binary x is 00111 and binary y is 01010, giving x = 7 and y = 10 at zoom 5. The exact bit ordering is documented in the Bing Maps specification.

Hierarchical aggregation

The Quadkey encoding makes a property of tile coordinates obvious: any prefix of a Quadkey identifies a parent tile that contains the full Quadkey's tile. So:

• “0” is a zoom-1 tile (the upper-left quadrant of the world)
• “02” is a zoom-2 tile (the lower-left of the upper-left)
• “021” is a zoom-3 tile (the upper-right of the lower-left of the upper-left)
• and so on

This makes tile coordinates a quadtree spatial index. Any point's zoom-5 Quadkey contains its zoom-4 parent, which contains the zoom-3 grandparent, and so on. This property is operationally useful for:

• Caching: a single zoom-3 tile contains 16 zoom-5 tiles; the zoom-3 parent can be served at lower bandwidth when fine detail is not needed.
• Spatial indexing: a database query for “all features in this region” can intersect with the relevant Quadkey prefixes rather than computing bounding boxes from scratch.
• Hierarchical aggregation: data aggregated at zoom 18 can be summed up to zoom 17 by combining each set of 4 child tiles, all the way up to zoom 0 (the global aggregate). The hierarchical rollup is fast because the parent-child relationship is encoded in the Quadkey itself.

Use across providers

Every major web mapping provider uses tile coordinates as the underlying coordinate system, even when their public APIs expose only latitude and longitude:

• Google Maps: uses (z, x, y) tiles via the https://mt[0-3].google.com/vt/... URL pattern. The Google Maps JavaScript API exposes tile coordinates via Projection and TileType objects.
• Apple Maps: uses the same (z, x, y) scheme for its proprietary tile service.
• OpenStreetMap / OSM: uses the canonical https://tile.openstreetmap.org/{z}/{x}/{y}.png URL pattern that the slippy-map convention is named after.
• Bing Maps: uses Quadkeys exclusively in URLs: https://ecn.t[0-7].tiles.virtualearth.net/tiles/a{Quadkey}.jpeg.
• Mapbox: uses (z, x, y) in raster URLs and (z, x, y) for vector tiles in MVT (Mapbox Vector Tiles) format.
• MapLibre: open-source library compatible with both raster and vector tile sources, using the (z, x, y) scheme.

The (z, x, y) ↔ Quadkey conversion is well-defined; software can move between the two encodings transparently.

Tile coordinates as a coordinate system

The qualification of (z, x, y) as a coordinate system is sometimes disputed because the tile coordinate identifies an area (the 256×256-pixel rectangle) rather than a point. Two perspectives resolve the dispute:

• For the purposes of data distribution, identification, and caching, tile coordinates are unquestionably a coordinate system: they provide a unique label for every spatial region in the Web-Mercator-projected world. The (z, x, y) triple is the authoritative identifier for the tile.
• For the purposes of point identification, (z, x, y) plus sub-tile pixel coordinates (px, py) gives a 4-tuple or 5-tuple that uniquely identifies any point at the chosen zoom level. The combined coordinate is the practical addressing scheme used internally by web mapping engines.

In either case, tile coordinates are the operational coordinate system of every modern web map. Latitude and longitude are the input; tile coordinates are the interchange format. The conversion between them is so universal that most map application code never sees the underlying lat/long after the initial input.

A worked example

Take Trafalgar Square in London (51.5080°N, 0.1281°W) at zoom level 15. Apply the tile-coordinate formulas:

n = 2^15 = 32,768
λ = -0.1281°
φ_rad = 51.5080° × π/180 = 0.8989 rad

x_tile = floor((-0.1281 + 180) / 360 × 32,768)
       = floor(16,372.4)
       = 16,372

y_tile = floor((1 - ln(tan(0.8989) + sec(0.8989)) / π) / 2 × 32,768)
       = floor(10,894.1)
       = 10,894

So Trafalgar Square at zoom 15 is the tile (15, 16372, 10894). The matching OpenStreetMap URL would be https://tile.openstreetmap.org/15/16372/10894.png — a single 256-pixel tile of central London at street-block scale. The corresponding Quadkey is “031313131313122” (15 base-4 characters encoding the same position via the parent-tile descent).

Sources

• Microsoft Bing Maps Tile System — the canonical Quadkey specification.
• OpenStreetMap Slippy map tilenames — the (z, x, y) URL convention.
• Google Maps Platform — coordinates and tiles
• Mapbox tilesets documentation
• EPSG:3857 Web Mercator

For closely related material, see /learn/slippy-map-tiles-explained for the operational side of tile-based maps, /learn/web-mercator-projection for the projection underneath, and /learn/geohash-explained for an alternative hierarchical spatial-indexing scheme.