mapbox/tippecanoe: building vector tilesets from large GeoJSON collections

The problem: zoomed-out maps that lie about density

Most tile pipelines simplify by dropping features they judge unimportant, or by clustering points and aggregating polygons. The result at low zoom is a map that shows the biggest downtown buildings and hides the neighborhoods. Tippecanoe's stated intent is to avoid exactly that: the README says the goal is a scale-independent view of your data, so that from the whole world down to a single building you see the density and texture rather than a simplification. The worked examples are OpenStreetMap, building footprints in Los Angeles, and years of tweet locations. The people who need this are cartographers and data engineers with a large GeoJSON, Geobuf or CSV file and a server to process it on, not application developers who want someone else to run the pipeline.

How tippecanoe decides what survives at each zoom

The command line is `tippecanoe -o file.mbtiles [options] [file.json file.json.gz file.geobuf ...]`. If no files are given it reads GeoJSON from standard input; if several are given, each becomes its own layer. Features need not be wrapped in a FeatureCollection, and the parser ignores objects that are not features, so concatenated files work.

The interesting part is the fallback chain. `-zg` picks a maximum zoom that should reflect the precision of the input. If tiles still come out too large, `--drop-densest-as-needed` drops what the documentation calls the least visible features at each zoom level, rather than clustering what remains. `--extend-zooms-if-still-dropping` keeps adding zoom levels until one can represent all the features. That is a different contract from simplification: you trade feature completeness at low zoom for a truthful density signal, and you accept a larger tile count. The repository layout backs this up: the build produces `tippecanoe`, `tippecanoe-enumerate`, `tippecanoe-decode`, `tile-join` and `tippecanoe-json-tool`, so inspection and joining are part of the shipped surface, not an afterthought.

Installing tippecanoe and producing a first tileset

On macOS the README gives Homebrew as the easiest route. Run this and you should end up with `tippecanoe` on your PATH:

brew install tippecanoe

On Ubuntu the README recommends building from source. The Makefile defaults to `PREFIX ?= /usr/local` and `make install` copies the binaries into `$(PREFIX)/bin`, so the second command needs write access to that directory:

git clone https://github.com/mapbox/tippecanoe.git
cd tippecanoe
make -j
make install

If the build fails, the README points to the Development section for upgrading the C++ compiler or installing prerequisite packages. The Dockerfile in the repository starts from `ubuntu:16.04`, installs `build-essential libsqlite3-dev zlib1g-dev`, runs `make && make install`, and sets `CMD make test`, which is a way to check the toolchain without touching your host.

The README's own first-use suggestion, for when you are unsure which options to pick, is:

tippecanoe -zg -o out.mbtiles --drop-densest-as-needed in.geojson

You should get an `out.mbtiles` file. If it is still too detailed, the README says to use `-z` manually with a higher number; if it drops too many features, use `-x` to leave out attributes you did not need. A more explicit example from the README names the layer and description and fixes the zoom:

tippecanoe -o alameda.mbtiles -l alameda -n "Alameda County from TIGER" -z13 tl_2014_06001_roads.json

Where tippecanoe is the wrong tool

The README itself opens with a pointer to Mapbox Tiling Service, described as a hosted, distributed and parallelized service, and gives a concrete contrast: a global basemap at 30cm precision (max zoom of 16) can be processed in under 2 hours with MTS, whereas a comparable workload would take multiple days on a single server. Tippecanoe is that single server. If your dataset is global and you need it rebuilt daily, the local tool is the wrong shape, and the README says so before it explains anything else.

There is a second boundary. The dropping behaviour is lossy by design. `--drop-densest-as-needed` removes features, and `-x` removes attributes. Neither is reversible after the fact, and the README does not document rollback or a way to recover dropped features from the output. If your use case is querying individual features rather than drawing a map, you want the source data, not the tileset. Finally, the build targets are Unix-oriented: Homebrew, a Makefile, and an `ubuntu:16.04` Dockerfile. The README does not document a Windows install path, so a Windows user is on their own.

The fork, and what to weigh against it

The most important line in the README is the note at the top: there is an active fork of this project at https://github.com/felt/tippecanoe. That is not a competitor in the usual sense, it is the same codebase under different stewardship, and it changes the adoption question from "is this tool good" to "which repository do I build from". The README of mapbox/tippecanoe does not explain what the fork adds or how the two diverge, so that comparison has to be made by reading the fork itself.

A genuine alternative in approach is Mapbox Tiling Service, which the README positions as the hosted successor for large-scale work. The difference is not a feature list. MTS distributes and parallelizes the job across machines and hands you a service; tippecanoe runs one process on one machine and hands you an `.mbtiles` file you own. If you need to run inside an air-gapped network, or you want the tileset as an artifact rather than an API response, the local tool is the one that fits. If you want the pipeline to scale past one server without you operating it, it is not.

Licence, upgrades and the cost of staying put

The repository is BSD-2-Clause, per the licence file at the top level. That is permissive: it allows use and redistribution with the copyright notice and disclaimer retained. It says nothing about the licence of the data you feed in, and it says nothing about what a fork's licence might be, so if you build a product on this, check the licence of the specific repository you clone. This is not legal advice.

The upgrade picture is the practical cost. The most recent release listed is 1.36.0 from 2020-08-26, described as updating Wagyu to version 0.5.0; before that, 1.35.0 in 2020-02-07 and 1.34.3 in 2019-05-16. The repository is not archived, and the last push was on 2026-06-29, so there is activity between releases, but the release cadence visible in the repository is slow. Upgrades are source builds: `make -j` then `make install`, or `brew install tippecanoe`. There is no documented migration path between versions, and the CHANGELOG is the place the repository keeps that record. For a tool that produces a static artifact, slow releases are survivable; for a tool you run in CI against changing input, pin the version you build.

Editorial conclusion

Adopt mapbox/tippecanoe if you have a bounded GeoJSON, Geobuf or CSV dataset and a server you control, and you want tiles that preserve density rather than cluster it away. Do not adopt it if you need a hosted, distributed pipeline at global scale, or if you expect the upstream repository to keep pace: the README points to an active fork at github.com/felt/tippecanoe, and the last push to this repository was on 2026-06-29. Before committing, run your own data through `tippecanoe -zg -o out.mbtiles --drop-densest-as-needed in.geojson` on the machine you intend to use, and check the resulting mbtiles with `tippecanoe-decode` before you wire it into a tile server.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. mapbox/tippecanoe on GitHub
4. README
5. Releases