Custom basemaps: when to replace the default world map

Most interactive maps live on top of a generic world basemap — the same one you see in any mapping product, sometimes with a colour shift or a label trim. That’s the right call for the vast majority of maps. But there’s a category of map where the generic world basemap actively gets in the way, and for those, swapping in a custom basemap is the highest-leverage decision you’ll make.

The trick is knowing which category you’re in before you spend a weekend building custom tiles you didn’t need.

The test: is the basemap helping or distracting?

Open your map. Look at it for ten seconds. Ask one question: is the basemap helping the viewer understand the regions, or is it competing with them?

• Helping — the basemap shows context the viewer needs (street names, geography, terrain) that the regions sit naturally on top of.
• Competing — the basemap is full of detail irrelevant to your map (hundreds of POIs, a busy road network, dense labels) that the viewer’s eye keeps catching first.

If the answer is “helping”, leave the default basemap alone. If the answer is “competing”, you have three options, in increasing order of effort: tone down the default, swap to a different generic basemap, or build a custom one.

Option one: tone down the default

The cheapest move is to take the default basemap and adjust its style. Reduce the saturation. Hide the POIs. Lighten or darken the entire thing so your regions sit clearly on top. Most maps that “need a custom basemap” actually need a 15-minute style adjustment of the default one. Try this first; it’s reversible and free.

Things to tone down, in order of impact: POI markers (turn them off entirely), label density (hide all but neighbourhood and street names), road colour (push toward grey), and the overall colour temperature (push toward neutral so your region colours pop).

Option two: swap to a different generic basemap

If toning down the default doesn’t do it, the next-cheapest move is to swap to a different generic style. Satellite imagery is great when geography matters and the viewer recognises the terrain. Terrain/topographic basemaps work well for outdoor or hiking-style maps. Dark vector basemaps look striking under bright region colours. Light vector basemaps are the safe default for almost anything else.

The cost is mostly cognitive: every basemap style is a different aesthetic, and switching mid-project means re-checking that all your region colours still work. Do this once, early.

Option three: build (or upload) custom tiles

Custom tiles are the right answer when:

• Your map isn’t Earth. A fictional world, a game world, a fantasy setting, an indoor floor plan, a stadium layout — anything where the standard mercator-projected world map is physically wrong.
• You need a stylised look the default can’t provide.Hand-drawn, painterly, retro pixel-art, blueprint-style — these all mean custom tiles.
• You need to strip the basemap to almost nothing.Sometimes the right basemap is a flat colour with subtle texture, so the regions can carry 100% of the meaning.

For everything else, custom tiles are overkill. They’re a real undertaking — design, export, hosting, zoom-level testing — and it shows when they’re half-built.

The file formats that actually work

Custom tiles come in two main shapes: raster (pre-rendered images, one per tile per zoom level) and vector (geometry that the renderer draws on the client). Both work; they have different trade-offs.

• Raster (PNG/WebP tiles) — easier to produce, easier to host, looks exactly like the source artwork. Heavier on bandwidth, doesn’t scale well past zoom 16 (gets pixelated), no live restyling. Right answer for stylised art and small worlds.
• Vector (MVT) — much smaller, scales infinitely without pixelation, can be restyled live (dark mode, label toggles, colour shifts). Harder to produce, requires real geometry data, less forgiving of aesthetic ambition. Right answer for large worlds and production-grade maps.

For a first custom basemap, start with raster. The path from “artwork” to “tile set” is well-trodden and the result is usually closer to what you imagined.

Zoom levels: pick a range, don’t pick “all”

A custom tile set has to render at every zoom level you support. That sounds obvious; in practice it’s the source of most custom basemap pain. A tile set that looks great at zoom 12–16 looks embarrassing at zoom 5 (everything blurs into a single rectangle) and unusable at zoom 19 (pixels everywhere).

The fix is to pick a sensible zoom range up front and clamp the map to it. For a city-scale custom map, 10–18 is usually enough. For a building-interior map, 16–20. For a fictional world, design the artwork for one specific zoom level and let it scale ± two levels around it. Trying to be perfect at every zoom is the fastest way to ship nothing.

Hosting, simplification, and the upload step

Tile sets are a lot of files. Even a small custom basemap can be thousands of tiles once you account for every zoom level. Two guidelines:

• Use a CDN, not your application server. Serving tiles from your app server is slow, expensive, and bad for caching. Object storage with a CDN edge in front of it is the standard pattern; most map platforms (Turf-map.io included) handle the hosting for you when you upload a tile set.
• Compress your images aggressively. A custom tile doesn’t need to be a 4MB lossless PNG. Run the whole set through an optimiser; you’ll usually shrink it 60–80% with no visible quality loss.

The boring takeaway

Custom basemaps are a powerful tool that most maps don’t need. The default basemap is the right answer for almost everything, and the 15-minute style-adjustment beats the weekend-long custom tile project 90% of the time. When you genuinely need a custom basemap — fictional world, indoor map, deep stylistic aesthetic — they’re great. Just make sure you’re solving the actual problem, not building tiles because they’re cool.