Why the map arrives in squares

The case for the square

A web server has no idea what part of the world a visitor wants to look at. It cannot pre-render a bespoke image for every possible pan-and-zoom combination — the combinations are effectively infinite. What it can do is cut the map into a fixed grid of same-size pieces and render every piece in advance. When a user pans north-east, the client asks for the relevant tiles from that grid, and the server fetches images it already has.

That is the entire logic of tile-based delivery, and it is older than it looks. The scheme that became ubiquitous — 256 × 256 pixel squares on a Mercator base, arranged in a zoom pyramid — emerged in the early 2000s and was popularised by mapping services that needed to shift large quantities of cartographic data to consumer browsers over modest connections. The insight was not cartographic; it was logistical. A fixed square is a key. A key maps to a row in a cache. A cache hit costs almost nothing.

The square specifically — rather than a hexagon or an irregular shape — wins on arithmetic. A 256-pixel tile at zoom level 0 covers the whole world. At zoom level 1, four tiles cover it; at level 2, sixteen; and so on, each level quadrupling the tile count. This pyramid, level by level, means any tile can be addressed with three integers: zoom, column, row. Routers, caches, and content-delivery networks can operate on those integers without knowing anything about geography. The simplicity is the point.

What the grid commits you to

Choosing tiles means choosing a projection, because the grid must tessellate the plane. The Web Mercator projection — formally EPSG:3857 — wraps the world into a square, which is why it dominates tiled maps. It is not the only option, and it has real costs: area distortion grows toward the poles, and the projection is formally unsuitable for navigation or area comparison. But it made the arithmetic work, and so it stuck.

The tile size of 256 pixels is similarly arbitrary and durable. It fit the screen hardware and bandwidth of its era. Some pipelines now emit 512-pixel tiles to serve high-density displays, which cuts the number of network round-trips by three-quarters while quadrupling each tile's byte weight. The trade-off between tile count and tile size is purely empirical — no projection theorem decides it.

Plate 2

Line weight was a physical choice before it was a style rule — one nib, one width, and the hierarchy came from the set.

Photo: Thirdman / Pexels

What the grid cannot do is handle features that cross tile boundaries cleanly. A label, a river, a political border — anything that spans two or more tiles must be handled specially, either by rendering it into every tile it touches (risking duplication or clipping) or by compositing it in the client after assembly. This is the seam problem that tiled delivery introduces and that every pipeline has to resolve. The square is efficient precisely because it is self-contained; anything that escapes that containment breaks the efficiency.

Caching is where the economics crystallise. A tile served a million times costs the same to produce as a tile served once — the render happened in advance. This is why static tile sets can be served from object storage or a simple file server with no database behind them: the tile address is the filename. Web infrastructure that was designed for documents, images and video serves maps without modification, because a tile is just a small image with a predictable name.

The shape of everything downstream

The square tile did not just determine how maps are delivered; it shaped how they are made. Cartographers design for tile boundaries, generalise features at each zoom level rather than continuously, and make styling decisions knowing that a tile will be rendered in isolation from its neighbours. Data pipelines are structured around the zoom pyramid. The whole production workflow is downstream of the delivery constraint.

That is unusual in cartography, where the map has traditionally driven production. With tiled delivery the infrastructure led, and the cartography followed. The square was a server engineer's convenience, and it reorganised how maps are designed, stored, and thought about — which is why understanding the delivery model is not optional for anyone making maps that will be served on the web.