Why Minecraft’s /locate Doesn’t Always Find the Nearest Village

I checked a seed map against the official Java server 2,580 times. Every structure matched. And in a third of the village lookups, the game’s own answer was not the closest village.

I build a browser-based Minecraft seed map, and the question I get most is “how do you know it’s right?” So this November I ran a test against the official Minecraft Java server instead of trusting my own code.

The setup was simple. Twenty seeds the map had never been tuned on. Three starting points per seed. For every structure type, ask the real server with /locate, then ask the map the same question, and compare the answers chunk by chunk. Java 26.3 and Java 1.21.4, the official server jar, run on GitHub Actions so anyone can rerun it.

All 2,580 answers landed in the same chunk. That part was the goal.

The surprise was somewhere else. When I compared the map’s “nearest village” with the server’s /locate answer, they disagreed in 20 of 60 cases in Java 26.3 (21 of 60 in 1.21.4). Every time, I asked the server again, standing at the map’s answer, and the server confirmed a village really starts there. It was closer than the one /locate had named.

So the map wasn’t wrong. /locate just isn’t a “nearest” search. Here’s why.

Where structures can go

Minecraft doesn’t scatter villages at random. For most structures it cuts the world into a grid of square cells and gives each cell exactly one candidate spot.

For villages in Java 1.18 and later, a cell is 34 × 34 chunks, or 544 × 544 blocks. Inside each cell the game picks one candidate chunk, somewhere in the first 26 × 26 chunks of the cell, so two villages are never closer than 8 chunks apart.

Where exactly? The game seeds a random number generator with the world seed, the cell’s coordinates and a fixed number (a “salt”) that is different for every structure type:

setSeed(cellX * 341873128712 + cellZ * 132897987541 + worldSeed + salt)
x = cellX * 34 + nextInt(26)
z = cellZ * 34 + nextInt(26)

For villages the salt is 10387312. Trial chambers use 34-chunk cells with a 22-chunk range and salt 94251327. Ancient cities use 24-chunk cells with a 16-chunk range and salt 20083232.

Then comes the filter. A village is only built if the biome at the candidate spot allows one: plains, meadow, desert, savanna, taiga or snowy plains. Ancient cities need the deep dark. A lot of candidate spots fail, which is why you can walk across an ocean or a jungle for a thousand blocks without seeing a village.

Notice what this means: everything above depends only on the seed and the coordinates. You don’t have to generate the world to know where villages can be. That’s the whole trick behind seed maps.

Why /locate skips the nearest one

/locate searches cell by cell, not block by block.

Get Geektao’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

It starts with the cell you’re standing in. If there’s no village there, it checks the ring of 8 cells around it, then the ring of 16 around those, and so on, up to 100 rings out. Within a ring it visits the cells in a fixed order (west to east, and north to south within each column), and it stops at the first village it finds.

Positions are made up for the example. The cell size, candidate area and scan order are the real ones for Java villages.

The catch is that a candidate can sit anywhere in the first 26 × 26 chunks of its cell. If the cell checked first has its village in the far corner, and a cell checked later has one right next to you, /locate still answers with the first. In the diagram, it reports village A, about 830 blocks away, while village B is about 340.

Strongholds are the exception. They aren’t placed on a grid but in rings around the world center, and for them the server does compare every candidate and returns the nearest.

In my test, /locate named something other than the nearest one in 20 of 60 village lookups, 12 of 60 for trial chambers and 15 of 60 for ancient cities (Java 26.3). In a few more cases two villages were at almost the same distance.

What a seed map does instead

A seed map runs the same placement rules for every cell on screen, drops the candidates that fail the biome check, and measures the real distance to each one. Then “nearest” means nearest.

Seed 123456789 in Java 26.3: every village around spawn at once, and the five nearest listed with their distance.

It also shows you all of them at once, which /locate can’t: it answers one structure per command.

What this means in the game

/locate is still the quickest answer when cheats are on, and the village it gives you exists. Just don’t read it as “the closest one”. A few practical things:

• If distance matters, run /locate again from a different spot, or check the cells next to the answer.
• /locate measures from where you stand, not from spawn.
• Clicking the coordinates in Java fills in a teleport command that keeps your current height, so on hills you may land in the air or inside one.
• Pick the right version on any seed map. Village cells were 32 chunks before Java 1.18, so old worlds have their villages in other places.

The full report, with the seed list, the method and every mismatch, is on the Seedari accuracy page. If you want to try your own seed, the village finder shows the nearest ones with coordinates.

Limits of the test: answers are compared at chunk level, 60 queries per structure type and version, Java only. Bedrock Edition places structures differently.

This article was drafted with AI assistance and checked against the test data and the Minecraft source rules.