How Accurate Is a Minecraft Seed Map?
JavaBedrockA seed map is a prediction, and predictions should come with their error bars. This is how ours is made, how we tested it against worlds generated by the real game, and what each accuracy badge promises, so you know when to trust a coordinate and when to bring a spare hour.
Updated · 7 min read · Java & Bedrock up to 26.3
Where the map's data comes from
Minecraft world generation is deterministic: the same seed, edition and version always produce the same biomes and the same structure positions. The map reproduces that generation with cubiomes, an open-source C library that re-implements the game's biome noise and structure placement for Java 1.7 through 26.3, extended with Bedrock's placement algorithms. We compile it to WebAssembly and run it in Web Workers in your browser, so a coordinate you read on the map was computed on your own device a moment ago, not looked up from a database.
A re-implementation can drift from the game, especially after an update, so we do not take its correctness on trust. The engine is verified against worlds generated by the official game, and the result of that verification is what the badges on each finder summarise.
How we test against the real game
For Java we run the official Mojang server jar for each supported recent version, generate fresh worlds for several seeds, and interrogate the game over its console. For every structure type we ask the game /locate structure from a dozen origins per world and compare its answer with the map's nearest structure from the same origin. When they disagree we ask the game again from the map's own coordinates, so a wrong map answer is classified either as missing (the game has it, the map does not) or as a phantom (the map shows it, the game does not). Phantoms are the number that matters most, because a phantom is a trip to an empty field.
Spawn is compared with the world's level.dat, strongholds are checked ring by ring, slime chunks against an independent implementation of the Java formula, and biomes with /locate biome at hundreds of points. For Bedrock we run the Bedrock Dedicated Server and test whether a structure exists at each map marker, because Bedrock's locate command does not return the nearest structure.
The latest run covered ten Java worlds on 26.3 and 1.21.11 (seeds 0, 123456789, -1234567890123, 8675309123456789 and the text seed chunkscout) and several Bedrock worlds. The full tables are in the project's verification report; the next sections give the headline figures.
Java results
| Check | Result |
|---|---|
| World spawn | 0 blocks off level.dat on all 10 worlds |
| Strongholds | 12 of 12 origins per world agree with the game |
| Biomes | 230 of 230 sample points per world |
| Slime chunks | 500 of 500 per world (algorithmic check) |
| Villages, monuments, mansions, outposts, ancient cities, trial chambers, fortresses, bastions, End cities, shipwrecks, ruined portals | 60 of 60 nearest matches, 0 phantoms (1 of 300 for villages and ruined portals) |
| Desert temples, trail ruins | 59 of 60 nearest matches, 0 phantoms |
| Jungle temples | 57 of 60 nearest matches, 0 phantoms |
| Mineshafts | 60 of 60, about 2% phantoms (position is the origin chunk) |
| Abandoned camps (26.3) | 60 of 60, 2% phantoms |
The few misses are structures the game skips for terrain reasons after choosing the position: a jungle temple whose corner sits exactly at sea level, for example. The map never showed a structure the game did not have for the exact types, which is the property you want when you are about to walk 2,000 blocks.
Features that are not structures get their own tests. Dungeons are simulated against the terrain and caves and about 86% of the ones shown were found in-game; ravines replay the canyon carver and 97.5% of their path was confirmed; chest loot for desert temples and ruined portals matched item for item, which is what the enchanted golden apple finder relies on.
Ore results
The ore finders are checked block by block: we read every ore block in several 7×7-chunk boxes out of worlds generated by the official server and compare the inner chunks with what the engine predicts. Two numbers describe each ore. Precision is the share of blocks the finder shows that really are that ore; recall is the share of the game's ore blocks the finder shows.
| Ore | Precision | Recall |
|---|---|---|
| Diamond | 97.2% | 98.9% |
| Ancient debris | 100% | 100% |
| Emerald | 99.5% | 100% |
| Gold | 96.5% | 97.5% |
| Iron | 99.4% | 86.0% |
| Redstone | 97.8% | 99.7% |
| Lapis lazuli | 99.0% | 99.6% |
| Copper | 99.6% | 83.7% |
| Coal | 88.5% | 88.8% |
Iron and copper recall is lower because part of their ore comes from the large veins, which the separate vein layer covers; with both layers on, recall is 99.6%. Coal is the weakest ore because it generates near the surface, where the engine's terrain model is least certain, and that is why most coal deposits carry the Likely mark instead of Exact.
Bedrock results
Bedrock is tested by existence: does the game generate the structure at the map's marker, yes or no. Villages, outposts, trial chambers, fortresses, mineshafts, ocean ruins, ruined portals and temples are confirmed at or near every marker and carry an Exact badge. Monuments, mansions, shipwrecks, buried treasure, ancient cities, bastions and strongholds are confirmed at between roughly half and nine in ten of their markers, with no real structure missing, and carry an Approximate badge.
End cities on Bedrock failed completely in testing, with none of the Java-rule positions present in the Bedrock End, so they are marked Java only and hidden on Bedrock maps. The same rule applies to the Bedrock Nether biome layer, which the engine cannot reproduce and the map therefore does not draw.
What each badge promises
| Badge | Promise |
|---|---|
| Exact | Same algorithm as the game; the structure is at this chunk. Travel without a plan B. |
| ±1 chunk | The marker is the origin chunk of something larger, such as a mineshaft, which spreads over several chunks. |
| Approximate | The game attempts the feature here; terrain can cancel or move it. Worth a look if it is on your way. |
| Java only | Bedrock placement is not implemented for this type, so Bedrock maps show nothing at all for it. |
| Likely (ores) | A deposit that rests on an approximation in the terrain model, drawn fainter. Still right about nine times in ten. |
The badges are set from measurements, not from how confident we feel. When a new game version changes generation, the verification is run again before the version appears in the list, and a type that fails is downgraded or hidden until the engine catches up.
When the map will still be wrong
- Wrong version. Chunks generated in an older version keep their old layout. Set the version that generated the area you are looking at.
- Edited worlds. Structures removed or added with tools, or chunks regenerated by a plugin, obviously do not follow the seed.
- Custom world types. Amplified, superflat and data-pack worlds use different generation; only Default and Large Biomes are supported.
- Spawn in unusual terrain. The spawn marker is an estimate that depends on grass blocks the engine does not model; it has matched in every test so far, but it stays labelled approximate.
- Snapshots and betas. Pre-release generation changes week to week and is not supported.
If you find a position that is wrong for a supported version, send us the seed, edition, version and coordinates through the contact page. A link copied from the map contains all of it, and real mismatches go into the next verification run.
Questions
Is the seed map always right?
For structures marked Exact on a supported version, every test against the official Java server agreed, with at most one phantom in 300 markers. Approximate and Java only badges tell you where the map knows less.
How can you test against the real game?
By running the official server for Java and the Bedrock Dedicated Server for Bedrock, generating worlds from the same seeds, and asking the game with /locate and existence checks whether each map position is real.
Why are some Bedrock structures only approximate?
Bedrock cancels some placements after choosing them, for reasons the engine cannot see. The attempt positions are correct, but only part of them become real structures, so the badge says so.
Do you verify every version?
Every new version is run through the same tests before it is offered in the version list. Older versions were verified when they were added and their generation does not change.
Is any of this done on your servers?
No. The engine runs in your browser; the server only hosts the files. The verification runs happen offline on a machine running the game, and their results are published in the project's report.
Related guides
Finders and tools in this guide
- Seed MapInteractive biome map with every structure, slime chunk and spawn point on one canvas.
- Ancient City FinderDeep dark cities with the warden, sculk and swift sneak books.
- Diamond FinderJavaEvery diamond in your Java seed with exact X Y Z, vein size and cave exposure.
- Dungeon FinderJavaMob spawner dungeons with Y level, mob type, chests and double-spawner spots for XP farms.
- Ravine FinderJavaEvery ravine with its path, width and depth, and whether it opens to the surface.
- Enchanted Golden Apple FinderJavaChests that hold a notch apple: desert temples and ruined portals, from the real loot tables.
- Slime Chunks ExplainedHow slime chunks work on Java vs Bedrock, and how to farm them.
Written by the Minecraft Tools team from the same world-generation engine that runs the seed map. Coordinates quoted here were computed with it for the stated seed, edition and version, and the engine is tested against the real game.