MI

Minecraft Overviewer

Generates browsable map tiles from Minecraft worlds

Game Servers ★ 3.5k stars Medium setup GPL-3.0

Minecraft Overviewer is a tool that renders high-resolution, interactive web maps from Minecraft worlds. The generated map can be self-hosted as a static website to let players explore the world in a browser.

Key features

  • Interactive world maps
  • Static site output
  • Player and POI markers
  • High-detail rendering

Pros & cons

Strengths

  • Beautiful map output
  • No live server load

Trade-offs

  • Rendering is slow
  • Not real-time

Minecraft Overviewer replaces

Last reviewed Sep 13, 2026 · 831 words

Minecraft Overviewer makes the best-looking static web map of a Minecraft world that you can self-host, and it is the wrong tool for most live servers in 2026. Development has slowed to a crawl and the renderer has not kept pace with recent Minecraft releases, so new blocks show up as gaps or placeholders. Rendering a large world takes hours of CPU. If your server runs a current version and players want to see each other move, install BlueMap as a plugin and stop reading. If you have an old world, a finished world, or a world you want to publish as a permanent website with zero load on the game server, Overviewer is still the tool I would reach for.

It is a command-line renderer, not a server plugin

This is the distinction that explains everything else. BlueMap and Dynmap run inside the Minecraft server and render as chunks change. Overviewer is a Python program you run on a copy of the world directory, on any machine, whenever you like. It writes out a folder of HTML, JavaScript, and thousands of PNG tiles, and that folder is the entire product. Serve it with Caddy or nginx, drop it in an S3 bucket, or open index.html from disk; nothing needs to run. The game server never sees a render job, which is the one thing plugin-based maps can never promise on a loaded 2 GB server.

Because it renders textures rather than colours, it needs a Minecraft client jar for the block textures. It looks in the standard ~/.minecraft/versions/ path and otherwise takes a --textures flag pointing at a jar or resource pack.

The config file is where the good renders come from

You can render with a single command (overviewer.py /srv/mc/world /srv/www/map), but a config file is what turns it from a screenshot into a map worth linking:

worlds["survival"] = "/srv/mc/world"
outputdir = "/srv/www/map"
texturepath = "/opt/minecraft/1.16.5.jar"

renders["day"] = {
    "world": "survival",
    "title": "Overworld",
    "rendermode": "smooth_lighting",
    "dimension": "overworld",
}
renders["night"] = {
    "world": "survival",
    "title": "Night",
    "rendermode": "smooth_night",
    "dimension": "overworld",
}
renders["nether"] = {
    "world": "survival",
    "title": "Nether",
    "rendermode": "nether_smooth_lighting",
    "dimension": "nether",
}

Run it with overviewer.py --config=map.py. Each render becomes a layer toggle in the finished map. Player and point-of-interest markers come from the companion genPOI.py script, which reads player data and signs from the world and writes marker JSON into the output; a filter function in the config decides which signs count. That is how people get "all the villages" or "every base sign" overlays without touching the server.

Render time is the price, and incremental renders soften it

Budget the 1 GB minimum RAM and a lot more CPU time. My rough numbers from a mid-sized survival world of about 4 GB on disk: a first full render across four render modes took the better part of an afternoon on 8 cores. That is why the first run should happen on your desktop rather than the server. After that, Overviewer only re-renders tiles whose chunks changed since the last run, so a nightly cron on a moderately active world finishes in minutes. Use --processes to match your core count and --check-tiles after a crash or an interrupted run. Treat the timings above as one person's experience, not a benchmark; terrain complexity and render modes change them by a factor of 5.

What it will not do

No live player positions, no in-game commands, no automatic updates as people build. Any 3D view: BlueMap's browser-based 3D is a different product entirely. Modern blocks on a world newer than the renderer understands, which is the deciding problem for active servers. And there is no web UI or daemon, so "install" means a Python environment with the compiled C extension, which the project ships as packages for Debian and Ubuntu and which you build from source elsewhere. None of that is a fault when the job is publishing a finished world; all of it is a fault when the job is a living map.

What I'd do

For any active server on a current version, BlueMap, no contest. For a world you have retired, a creative build you want to show off, or a Minecraft server that is already at capacity and cannot afford a plugin doing render work, Overviewer once a week from cron on a separate machine, output synced to a static host behind Caddy. Keep the client jar that matches the world version next to the config, because textures are the first thing to break when you move the render job. It is a niche tool from 2010 with 3,498 stars and a slow pulse, and for that niche it still produces the map everyone else is imitating; see the rest of the games category for the servers it pairs with.

Compare Minecraft Overviewer

1 head-to-head comparisons.

Similar game servers apps