Vector Tiles Explained

This article continues the Web Mapping & Tile Systems sub-hub. The /learn/slippy-map-tiles-explained article covered the addressing scheme common to both raster and vector tiles; this article goes deeper on the vector-tile format, which has displaced raster tiles as the dominant choice for new interactive web maps.

What vector tiles are

A vector tile contains encoded vector geometry for a tile-bounded area — points, lines, polygons with attributes — rather than a pre-rendered raster image. When fetched by a client, the tile is rendered client-side at the current viewport resolution and chosen styling.

The format differences:

| Aspect | Raster tile | Vector tile | | ------ | ----------- | ----------- | | Content | Pixel grid (PNG, JPEG, WebP) | Vector geometry + properties | | Extension | .png / .jpg / .webp | .pbf / .mvt | | Encoding | Standard image format | Protocol Buffers (Google) | | Size (typical) | 5-50 KB | 5-200 KB (varies by content) | | Render time | Instant (display image) | Client-side WebGL rendering | | Styling | Baked into image | Applied at render time | | Interactivity | Click → no info | Click → feature query |

The Z/X/Y addressing is identical to raster tiles (see /learn/slippy-map-tiles-explained). The same URL pattern /Z/X/Y.pbf applies; only the file content differs.

The Mapbox Vector Tile (MVT) format

The Mapbox Vector Tile (MVT) specification is the dominant format for vector tiles. Published openly by Mapbox in 2014 at github.com/mapbox/vector-tile-spec under a BSD-3-Clause license.

Structure

An MVT file contains:

• Layers: each layer is a separate logical group (e.g., “roads”, “water”, “buildings”).
• Features: each feature has a geometry and a set of property key-value attributes.
• Geometries: encoded as sequences of commands (MoveTo, LineTo, ClosePath) with parameters using zigzag-and-delta encoding.

The whole structure is serialized using Google Protocol Buffers for compactness — a binary format with explicit field type definitions, much smaller than JSON or XML for the same data.

Coordinate system

MVT coordinates are normalized to a 0-4096 grid within the tile (or another power-of-two extent; 4096 is conventional). The renderer reprojects from this internal grid back to Web Mercator and then to screen pixels.

Why integer coordinates? Smaller encoding size (1-2 bytes per delta vs 4-8 for floats); easier to compress with delta encoding; sufficient precision within a tile (4096 steps per ~256m at high zoom is ~6 cm).

Feature geometries

Three geometry types:

• POINT (1): single-point or multi-point.
• LINESTRING (2): one or more line segments.
• POLYGON (3): one or more polygons with optional holes.

The actual geometry is encoded as a command stream:

MoveTo(dx, dy)        # Start a new sub-path
LineTo(dx, dy)        # Continue line
ClosePath()           # Close current polygon ring

Each command is encoded with a small integer (the command ID and a count), followed by zigzag-encoded delta coordinates (delta from the previous point). The zigzag encoding maps small negative numbers efficiently into the variable-length integer encoding used by Protocol Buffers.

Feature properties

Each feature can have key-value properties:

{
  "name": "Times Square",
  "kind": "plaza",
  "min_zoom": 14
}

Properties are stored as references into per-layer key tables and value tables, avoiding repeated strings across the tile. This compression matters because a tile may have thousands of features sharing property names.

Compression

MVT files are typically gzipped in transit (HTTP compression). After gzip, a typical road-tile at zoom 14 is 5-15 KB — comparable to a JPEG image of much lower content density.

Why vector tiles

The fundamental advantage: the same tile data can be styled and rendered many different ways, without re-fetching.

Runtime restyling

Switch from a light theme to a dark theme: just change the style specification; the same tile data renders differently. No re-fetching. Compare to raster tiles where each theme would require its own pre-rendered tile set.

Interactive features

Click on a road in a rendered vector map: the underlying feature can be queried for its properties (name, type, max speed). Raster tiles encode no such information — the pixels are just colors.

Sharper at all zoom levels

Raster tiles look pixelated when over-zoomed. Vector tiles render at the native screen resolution, so they stay sharp. This particularly helps high-DPI displays.

Data-driven styling

Vector tile styles can include filter expressions that select features based on property values:

{
  "id": "major-roads",
  "type": "line",
  "source": "vector-tiles",
  "source-layer": "roads",
  "filter": ["==", "kind", "highway"],
  "paint": {
    "line-color": "#ff6600",
    "line-width": 3
  }
}

This filters the roads layer to show only features where kind == "highway", with specific styling. Building rich thematic visualizations is straightforward.

Animation

Properties can drive animation. Color, opacity, line width can be made functions of the current zoom or of feature properties. The renderer interpolates smoothly between states.

The trade-offs

Vector tiles aren't universally better than raster:

Client compute

Rendering vector tiles requires client-side WebGL. Older browsers, low-power devices, and accessibility tools (screen readers, simplified browsers) may struggle. Raster tiles work on essentially any device.

Initial load

A single vector tile can be larger than its raster equivalent because it contains all feature data, not just the rendered colors. For a single tile load, raster is often faster. But because vector tiles don't need per-zoom re-fetching for restyling, the total bandwidth over a session is typically lower.

Rendering quality

Vector tile rendering is more complex. Edge cases in feature crossing tile boundaries, label placement, and 3D building rendering can produce artifacts. Raster tiles are rendered once on the server with full algorithms; vector tiles render under client constraints.

Specialized content

For photographic content (satellite imagery, ortho-photos, historical scanned maps), vector encoding doesn't help — the content is fundamentally pixel-based. Raster tiles are correct here.

Rendering libraries

MapLibre GL JS

The open-source community fork of Mapbox GL JS, created after Mapbox went closed-source in version 2.0. MapLibre is now the standard open vector-tile renderer. WebGL-based, ~700 KB minified JavaScript, supports the full Mapbox Style Specification.

Used in: Coordinately, OpenStreetMap.org demos, many open-source projects, and increasingly in commercial products that want open licensing.

Mapbox GL JS

The commercial original. Closed-source since v2.0 (2021); requires a Mapbox account and API token. Used in Mapbox-hosted maps and many commercial applications.

Cesium

3D globe rendering library that supports vector tiles for 3D rendering. Used in aerospace and large- scale visualization.

deck.gl

WebGL-based data visualization library from Uber. Can consume vector tiles as data sources for custom overlay rendering.

Server-side renderers

For pre-rendering vector tiles into raster:

• Mapnik: the OSM rendering library; powerful but complex setup.
• maptiler-engine: MapTiler's commercial rendering engine.

The Mapbox Style Specification

The Mapbox Style Specification is a JSON document that describes how vector tiles should be rendered. Published openly at docs.mapbox.com/style-spec/.

Structure:

{
  "version": 8,
  "name": "My Style",
  "sources": {
    "vector-tiles": {
      "type": "vector",
      "tiles": ["https://example.com/{z}/{x}/{y}.pbf"],
      "minzoom": 0,
      "maxzoom": 14
    }
  },
  "layers": [
    {
      "id": "water-fill",
      "type": "fill",
      "source": "vector-tiles",
      "source-layer": "water",
      "paint": {
        "fill-color": "#a0c4ff"
      }
    },
    {
      "id": "roads-primary",
      "type": "line",
      "source": "vector-tiles",
      "source-layer": "roads",
      "filter": ["==", "kind", "primary"],
      "paint": {
        "line-color": "#ffaa00",
        "line-width": ["interpolate", ["linear"], ["zoom"], 6, 1, 14, 4]
      }
    }
  ]
}

Key concepts:

• Sources: declare tile data origins.
• Layers: rendering rules, applied in order (later layers paint over earlier).
• Filter expressions: select which features to render.
• Paint properties: visual attributes.
• Layout properties: text fields, symbol icons, font choices.
• Expressions: data-driven values (interpolation, conditional logic).

The spec defines about 20 layer types, hundreds of paint and layout properties, and a rich expression language. Full mastery takes time; a simple style can be written in 100-200 lines.

Vector tile sources

OpenMapTiles

The dominant open vector-tile schema. Derived from OpenStreetMap data, with a stable schema that includes ~20 layers (water, land, roads, buildings, labels, etc.). Used by many self-hosted and commercial vector-tile services.

Free for non-commercial use; paid hosting via MapTiler.

Mapbox vector tiles

Commercial vector tiles from Mapbox. Multiple schemas: Mapbox Streets (general purpose), Mapbox Terrain, Mapbox Traffic. Pricing similar to raster tiles.

MapTiler vector tiles

MapTiler hosts OpenMapTiles-schema vector tiles and offers commercial styling and rendering. Free tier for low-usage; paid plans for production.

Protomaps

Open-source vector-tile base maps built on PMTiles (see below). Brandon Liu's project provides free OSM-derived global vector tiles at protomaps.com for hobbyist and small-scale use. Self-hosting via PMTiles is straightforward.

Self-hosted

Generate your own vector tiles from OSM data using Tippecanoe (Mapbox), t-rex, Tegola (Go), or OpenMapTiles. Storage and serving costs scale with usage.

PMTiles: tile-server alternative

PMTiles (developed by Brandon Liu, 2021–present) is a single-file archive format for tiles, accessed via HTTP range requests. Eliminates the need for a tile-server process: just host the PMTiles file on any HTTP server and serve it directly.

How it works:

1. The PMTiles file contains a header, an index of tile locations, and the raw tile data concatenated.
2. The client uses an HTTP range request to fetch just the bytes needed for the requested tile.
3. Modern CDNs (CloudFront, Cloudflare, S3) support range requests natively.

Use cases:

• Archived snapshots: PMTiles files are immutable; great for versioned data.
• Offline maps: a PMTiles file can be embedded in a mobile app for fully offline use.
• Self-hosting without infrastructure: drop a PMTiles file on S3 + CloudFront; no tile server needed.
• Open-data tile distribution: Protomaps publishes global OSM-derived PMTiles for download.

Supported by MapLibre GL JS via the pmtiles plugin and similar libraries for Leaflet, OpenLayers, Mapbox GL JS.

Vector tile generation

From PostGIS

PostGIS's ST_AsMVT function generates MVT geometry directly from a database query:

SELECT ST_AsMVT(tile, 'roads', 4096, 'geom')
FROM (
  SELECT id, name, kind,
         ST_AsMVTGeom(geom,
                      ST_TileEnvelope(z, x, y),
                      4096, 256, true) AS geom
  FROM osm_roads
  WHERE geom && ST_TileEnvelope(z, x, y)
) tile;

This pattern is common in dynamic vector-tile servers like Martin, pg_tileserv, and Tegola.

From Tippecanoe

Tippecanoe (Mapbox, open source) generates vector tiles from GeoJSON or other vector formats:

tippecanoe -o output.mbtiles -z 14 -Z 0 input.geojson

The .mbtiles output is an SQLite-based tile cache that can be served by various tile servers or converted to PMTiles.

From OpenMapTiles workflow

The OpenMapTiles project provides a Docker-based pipeline that generates global vector tiles from an OSM extract:

1. Import OSM data into PostgreSQL/PostGIS.
2. Apply the OpenMapTiles schema (SQL views and functions).
3. Generate vector tiles using Tippecanoe or Tegola.
4. Serve via a tile server or PMTiles.

The output is a complete, styled, multi-layer vector tile set ready for production use.

Specific use cases

Custom thematic maps

Map of points colored by some property (population, income, election results): trivial with vector tiles

• style spec; complex with raster.

Multi-language labels

Vector tile layers can include labels in multiple languages as separate property fields. The style spec selects which to render based on user locale or device settings. Mapbox Streets includes ~20 label languages.

3D buildings

Vector tiles can include building height as a property; the renderer extrudes into 3D in the viewport. Mapbox GL JS / MapLibre GL JS render this natively. Raster equivalents would require pre-rendered 3D views from each viewpoint.

Interactive feature query

Click any feature on the rendered map; the renderer returns the underlying property data. Powers “click for info” popups, contextual selection, and feature-based filtering.

Real-time data overlay

Vector tiles enable dynamic re-styling of static geometry with real-time data layers. Traffic visualization, COVID case maps, election results all use the pattern.

Common misconceptions

“Vector tiles render the same as a server would.” Not exactly. Client-side rendering has limitations (font support, complex label placement, accurate anti-aliasing). Server- rendered maps (Mapnik in OSM) often have cleaner labels and more sophisticated rendering.

“Vector tiles are always smaller than raster.” Usually but not always. A tile with thousands of features (dense urban areas) can exceed the equivalent raster tile size. Average, yes; for every tile, no.

“MVT is proprietary.” No — the Mapbox Vector Tile Specification is BSD-3-licensed open source on GitHub. Any client or server can implement it freely.

“You need a Mapbox account to use vector tiles.” No — MVT is an open spec; MapLibre GL JS is open-source; OpenMapTiles + Protomaps provide open base maps. The full stack is Mapbox-independent.

“Vector tiles only work with WebGL.” Practically yes for performant rendering, but non-WebGL renderers exist for specific use cases. The mainstream production renderers all use WebGL.

“PMTiles eliminates the need for any infrastructure.” Almost — you still need HTTP hosting that supports range requests (S3, CloudFront, GitHub Pages with caveats, Vercel). PMTiles is server-process-free, not infrastructure-free.

“The Mapbox Style Specification is just visual styling.” It also includes filter expressions, data-driven properties, and 3D rendering parameters. The full spec is more like a small declarative programming language than a CSS analog.

“Tippecanoe is the only vector-tile generator.” No — Tippecanoe is widely used but alternatives exist: PostGIS ST_AsMVT, Tegola, t-rex, Mapbox Tilesets API, openmaptiles-tools. Choose based on input format and operational needs.

“Vector tiles require a special tile server.” They can be served by any static HTTP server (S3, CloudFront, Nginx). Static hosting works for pre-generated tiles. Dynamic servers are needed only for on-the-fly generation from a database.

“The 4096-coordinate grid is a limit.” Yes, within a tile. But the grid is a power of two; 4096 means 6 cm precision at zoom 18, more than enough for typical mapping. Smaller extents are allowed (1024, 2048) if precision is even less critical.

“Vector tiles don't support satellite.” They do — many production maps use vector tiles for the interactive base layer plus raster tiles for satellite or aerial overlay. The two coexist as separate sources in the style spec.

“Vector tiles are deprecating raster.” For interactive base maps, vector tiles are displacing raster. For specialized content (satellite imagery, historical scans, photographic overlays), raster remains the right choice. Both formats will coexist for the foreseeable future.