Slippy Map Tiles Explained

This article opens the Web Mapping & Tile Systems sub-hub. The /learn/web-mercator-projection article in the Projections sub-hub covers the projection mathematics; this article covers the tile-addressing system built on top — the standard infrastructure of modern web maps.

What a slippy map is

A slippy map is an interactive web map you can pan and zoom — “slipping” the view around as you drag. Beneath the slick UI:

• The map at any moment is a grid of 256×256-pixel tile images (or 512×512 for high-DPI retina displays).
• As the user pans or zooms, the browser fetches new tiles from a tile server.
• The browser caches tiles locally and reuses them on subsequent pans through the same area.
• Each tile is identified by three coordinates: Z (zoom), X (column), Y (row).

The pattern was introduced by Google Maps in February 2005 and quickly imitated by OpenStreetMap (2006), Yahoo Maps, Mapbox (2010), and essentially every other interactive map provider since.

The Z/X/Y addressing scheme

The three coordinates define a position in the tile pyramid:

Z: zoom level

The zoom level. Each step doubles the resolution:

• Z=0: a single 256×256-pixel tile shows the entire world.
• Z=1: 2×2 grid (4 tiles) shows the world.
• Z=2: 4×4 (16 tiles).
• Z=N: 2^N × 2^N tiles total at that zoom.

The maximum zoom commonly supported: Z=18 or Z=19. Some providers (Google, Mapbox commercial) go higher to Z=22 or 23 for specific use cases. OSM's public tile server caps at Z=19.

X: column

The column index, increasing eastward. X=0 is the westernmost tile at the given zoom; X=(2^Z − 1) is the easternmost.

Y: row

The row index. In the XYZ convention (the modern default), Y=0 is the northernmost tile and Y=(2^Z − 1) is the southernmost — i.e., Y increases southward.

(See “XYZ vs TMS” below for the alternative convention.)

URL convention

A tile request typically looks like:

https://tile.openstreetmap.org/{z}/{x}/{y}.png

Concrete example: https://tile.openstreetmap.org/10/512/512.png fetches the Z=10, X=512, Y=512 tile.

The format extension varies:

• .png — most common raster tile format.
• .jpg / .jpeg — for satellite imagery (smaller than PNG for photos).
• .webp — modern compressed raster.
• .pbf / .mvt — vector tiles (see /learn/vector-tiles-explained).
• .json — TileJSON metadata.

The tile-coordinate math

Translating between tile coordinates and geographic (latitude/longitude) coordinates:

Lat/lon → tile

Given lat/lon and zoom Z:

n = 2^Z
x_tile = floor((longitude + 180) / 360 * n)
y_tile = floor((1 - asinh(tan(latitude * π/180)) / π) / 2 * n)

Worked example: Empire State Building, latitude 40.7484°, longitude -73.9857°, at zoom Z=14:

n = 16384
x = floor((-73.9857 + 180) / 360 * 16384) = 4825
y = floor((1 - asinh(tan(40.7484 * π/180)) / π) / 2 * 16384) = 6155

So the tile is /14/4825/6155.png.

Tile → lat/lon (top-left corner)

n = 2^Z
longitude = X / n * 360 - 180
latitude = atan(sinh(π * (1 - 2 * Y / n))) * 180 / π

For tile (10, 300, 400):

n = 1024
lon = 300 / 1024 * 360 - 180 = -74.53°
lat = atan(sinh(π * (1 - 800 / 1024))) * 180 / π = 40.98°

So tile (10, 300, 400) covers roughly southern New England.

Cell size at each zoom

The size of a tile in real-world units depends on zoom and latitude. At the equator:

cell_size_meters = 40,075,000 / (2^Z × 256)

(Earth's equatorial circumference 40,075 km divided by the number of tile-pixels around the equator at that zoom.)

| Zoom Z | Cell size at equator (m/pixel) | Use case | | ------ | ----------------------------- | -------- | | 0 | ~156,000 | World | | 3 | ~19,500 | Continental | | 6 | ~2,440 | Country | | 10 | ~152 | Large city | | 12 | ~38 | Small city / district | | 14 | ~9.5 | Neighborhood | | 16 | ~2.4 | Street block | | 18 | ~0.6 | Building | | 19 | ~0.3 | Architectural | | 22 | ~0.04 | Centimeter-scale |

At latitudes away from the equator, the real-world cell size shrinks (because Web Mercator stretches high latitudes). At latitude 60°, the cell size at any zoom is half what it is at the equator. At 80°, it's about 1/6.

XYZ vs TMS

Two conventions for the Y axis:

XYZ (slippy map / Google / OSM)

• Y=0 at the north (top of the world).
• Y increases southward.
• The convention popularized by Google Maps in 2005.
• Used by OSM, Mapbox, MapTiler, Apple, Bing (with caveats; quadkey internally maps to XYZ-like), and essentially all modern providers.

TMS (Tile Map Service)

• Y=0 at the south (bottom of the world).
• Y increases northward.
• An OGC standard predating Google Maps.
• Used by some older WMS-derived servers and some GIS workflows.

Conversion: TMS_Y = 2^Z - 1 - XYZ_Y. Most modern tile libraries handle the conversion transparently when configured for the source convention; mismatches produce maps that are vertically mirrored (a common debugging mystery).

Bing Maps and quadkeys

Microsoft Bing Maps uses an alternative addressing scheme called quadkeys:

Each tile is identified by a string of digits 0-3 with length equal to the zoom level. Each digit encodes a quadrant choice:

0 = top-left
1 = top-right
2 = bottom-left
3 = bottom-right

A zoom-3 tile might be 102:

• First step: top-right quadrant.
• Second step: top-left.
• Third step: bottom-left.

The path through the quadtree gives the same tile as a corresponding Z/X/Y triple. Conversion is mechanical:

def quadkey_from_xyz(x, y, z):
    s = ''
    for i in range(z, 0, -1):
        digit = 0
        mask = 1 << (i - 1)
        if x & mask: digit += 1
        if y & mask: digit += 2
        s += str(digit)
    return s

Quadkeys are useful for hierarchical caching and B-tree indexing in databases — the prefix relationship maps directly to spatial containment. Bing uses quadkeys natively; other major providers use Z/X/Y.

Major slippy-map providers

OpenStreetMap

The open standard. Free tiles at https://tile.openstreetmap.org/{z}/{x}/{y}.png.

OSM's usage policy limits free use to small-scale sites and applications; heavy users should host their own tile server or use a commercial alternative. OSM tile sources at scale must follow the Tile Usage Policy.

Mapbox

Commercial provider with extensive global coverage. Tiles via https://api.mapbox.com/v4/{style}/{z}/{x}/{y}.png?access_token=....

Pricing: typically $0.50-2 per 1,000 tile requests above the free tier (50,000/month).

MapTiler

Commercial provider with both raster and vector tiles. Coordinately's current map base uses MapTiler tiles (see project README).

Google Maps

The original, but heavily restricted by terms of service. Direct tile access generally requires the Google Maps Platform JavaScript API; raw tile URLs aren't officially supported.

Bing Maps

Available via Microsoft's API with quadkeys.

Apple Maps

Native iOS/macOS; no public web tile API.

National mapping agencies

Many national agencies publish their own slippy-map tiles:

• USGS — National Map tiles for the US.
• UK Ordnance Survey — OS tile services.
• IGN France — France-specific tiles.
• GeoBasis-DE — Germany.
• Geoscience Australia — Australia.

These typically have stronger coverage in their respective countries and may include specialized content (topographic, cadastral, hydrographic).

Performance considerations

Tile size

Standard: 256×256 pixels. Larger tiles (512×512) reduce the number of HTTP requests for a given viewport — better with HTTP/2 multiplexing — at the cost of doubled data per tile. Mapbox vector tiles use 512×512 by default; raster tiles typically remain 256×256.

Image format

• PNG: lossless, larger files, best for vector rendering and label clarity.
• JPEG: smaller, good for satellite/photographic imagery.
• WebP: modern, often 30% smaller than PNG with similar quality.
• AVIF: newest, even smaller, but slower decode.

Retina (2x) tiles

High-DPI displays request retina tiles — typically 512×512 pixels covering the same geographic area as a 256×256 tile, giving 2× pixel density. URL convention varies; some servers use @2x suffix (/Z/X/Y@2x.png), others use a separate endpoint.

Caching

Browsers, CDNs, and intermediate proxies cache tiles aggressively. Typical cache hit rates exceed 95% for popular tiles. See /learn/tile-servers-and-caching-explained for the operational details.

Limitations and edge cases

Pole exclusion

Web Mercator becomes infinite at the poles, so slippy maps clip at ±85.0511° (the latitude where the Mercator projection produces a square tile system exactly — atan(sinh(π)) in radians, ~85.0511°).

Polar and high-latitude regions are increasingly distorted as you approach the cutoff. Specialized tile schemes (UTM-based, polar stereographic) are used for high-latitude work.

Datum considerations

Web Mercator uses WGS 84 latitude/longitude as input but treats them as spherical (not ellipsoidal) during the projection — see /learn/web-mercator-projection. For sub-meter-precision applications, the spherical approximation introduces small errors (up to ~700 m at the limits, less at lower latitudes).

Date-line tiles

Tiles at the antimeridian (Z=N, X=0 and X=(2^Z−1) adjacent) can have edge artifacts; vector features spanning the antimeridian may not render correctly unless duplicated at both ends of the world.

Tile boundaries

Vector features crossing tile boundaries are clipped at the boundary in each tile. Properly rendered maps include features in both adjacent tiles so the visual continuity is preserved at any zoom.

WMTS: the OGC standard

The Open Geospatial Consortium (OGC) Web Map Tile Service (WMTS) is the standardized API for tile-based map services. WMTS:

• Defines GetCapabilities (server metadata), GetTile (tile request), and GetFeatureInfo endpoints.
• Supports both REST and KVP (key-value-pair) URL formats.
• Standardizes TileMatrixSet definitions for different projections (Web Mercator is the “GoogleMapsCompatible” matrix set).

Most slippy-map providers offer simpler URL templates (/Z/X/Y.png) alongside or instead of full WMTS, but WMTS is the formal standard for tile services in government and enterprise GIS.

Slippy maps in practice

A complete web-mapping setup:

1. Tile source: pick a provider (OSM, Mapbox, MapTiler, etc.) or self-host.
2. JS map library: Leaflet, OpenLayers, MapLibre GL JS, Mapbox GL JS, deck.gl, MapKit JS.
3. Initial view: center latitude/longitude + zoom level.
4. Overlays: vector layers, markers, popups, etc.
5. Interaction: pan/zoom handlers, click events.

The libraries handle:

• Computing which tiles are needed for the current view.
• Fetching tiles from the source URLs.
• Caching tiles locally.
• Stitching tiles into the visible map.
• Rendering vector overlays on top.
• Handling pinch/scroll/drag interactions.

For most projects, the developer chooses a tile source and a JS library; the integration is a few lines of code.

Common misconceptions

“Slippy maps work in any projection.” The standard scheme assumes Web Mercator. Other projections require non-standard tile schemes (NetSCH, polar stereographic, UTM-based). Tools like Proj4Leaflet support custom projections in Leaflet but it's additional setup.

“Tile pixels equal real-world distances.” No — the pixels are projected through Web Mercator. At low latitudes, 1 pixel ≈ small real-world distance; at high latitudes, 1 pixel ≈ much smaller real-world distance because Web Mercator stretches northward.

“Z/X/Y is universal.” Almost — but TMS (Y flipped) and Bing quadkeys are alternative conventions in active use. Check the source documentation.

“Higher zoom = better data.” Higher zoom = more pixels per area. The underlying data quality is independent — a Z=22 tile of an area without high-detail source data is just zoomed-in versions of the lower-zoom data, with no real improvement.

“OSM tiles are free for any use.” OSM tiles are free for small-scale use under the OSM Tile Usage Policy. Heavy users (high-traffic sites, production applications) must self-host or use a commercial provider. Violating the usage policy can result in IP blocking.

“Tile size is always 256×256.” Conventionally yes, but 512×512 is used for retina-quality tiles and some modern providers (Mapbox vector tiles default to 512). The choice affects bandwidth and request count.

“Tile boundaries are exact.” Yes for the bounding box, but rendered tiles often include a small buffer to ensure features don't cut off at boundaries. The buffer is server-side and invisible to the client.

“Slippy maps can't do raster zoom-out.” They can — the pyramid structure includes lower zoom levels (Z=0 is the whole world). The pyramid is finite at the high-zoom end (typically Z=18-22 max) but goes down to Z=0 (single tile).

“Web Mercator is the only choice.” No — WMTS supports other projections via TileMatrixSet definitions. Polar stereographic tiles exist for Arctic and Antarctic applications. UTM-based tile schemes exist for some national mapping products. But for the general-purpose web map, Web Mercator dominates.

“Tile URLs are public.” Commercial providers (Mapbox, MapTiler, Google) require API keys / tokens in the URL. The token allows the provider to track usage and bill. Hot-linking from a competitor's public-key-bearing URL is a TOS violation.