iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Prefer not to run the server on your own PC? Godlike.Host offers hosted Minecraft Java servers with free DDoS protection and up to three free backups a day.
Use a different method for each edition. In Bedrock Edition, activate a behavior pack that overrides the village-generating biome files and removes the minecraft:village_type component before creating the world. In Java Edition, the built-in Generate Structures switch turns off villages together with every other generated structure; keeping temples, monuments, and other structures requires a version-matched datapack that removes village entries from biome structure tags or related structure-set data. Neither approach removes villages from chunks that have already been generated.
What changes when you disable villages?
Villages are placed during terrain generation. A setting or data file can therefore affect only chunks generated after that rule is active. It cannot rewrite terrain that Minecraft has already saved. This distinction determines when to configure the world:
- New world: the rule can prevent villages throughout the world if every relevant biome or structure entry is covered.
- Existing world, unexplored area: newly generated chunks can follow the rule after the pack or datapack is enabled.
- Existing, explored area: villages already stored in those chunks remain. A generation pack is not a village-removal or world-editing tool.
There is no universal “villages off” gamerule that works identically in both editions. Bedrock reads village information from biome definitions, while Java uses world-generation registries, biome structure tags, and structure-set data. The result is that the same goal—preventing villages—requires different files and different timing in each edition.
Decide whether you want to remove every generated structure or villages only. That choice matters more than the convenience of a particular method: Java’s simple built-in switch is easy but broad, whereas selective removal requires files that match your exact release.
#1 Best Overall
- Play and share with friends on console, mobile and Windows 10
- discover community creations in the new in-game store
- access new mini games and game modes through servers
Choose the edition-specific route before changing files. Bedrock’s official approach edits biome definitions; Java’s selective approach edits world-generation data. They are not interchangeable.
Choose the right method at a glance
| Edition | Method | Scope | When to apply | Maintenance | Existing chunks |
|---|---|---|---|---|---|
| Bedrock | Behavior pack removing minecraft:village_type from overridden biome files |
Villages can be blocked while other structures remain | Ideally before world creation; can affect later, ungenerated chunks in an existing world | Biome files must be kept current with each Bedrock release | Previously generated villages remain |
| Java | Generate Structures: Off | All generated structures, including villages, are disabled | World creation | Built-in option; no file maintenance | Not applicable to a new world; it is a creation-time rule |
| Java | Version-matched datapack changing village structure tags or structure-set data | Villages only, while other structures can stay enabled | Use for a new world or unvisited chunks | High; identifiers, directories, and pack format vary by release | Previously generated villages remain |
Use the first Bedrock row when you want other structures to continue generating. Use Java’s built-in switch only when a structure-free world is acceptable. If you need villages gone but temples, monuments, and other structures preserved in Java, skip the switch and plan for a release-specific datapack.
Bedrock Edition: block villages with a behavior pack
Microsoft’s official guidance says village generation is controlled by the minecraft:village_type component in biome definition files. The practical solution is to copy the current definitions into a behavior pack, remove that component from each biome you want to change, and enable the pack before generation.
This is a data override, not a command that runs after a village appears. The pack must be recognized by the world before Minecraft creates the relevant chunks. If the pack is active but a biome file is absent, that biome continues using its normal definition and can still generate its usual village type.
1. Decide whether you need a complete block
For a vanilla-style world with no villages in the biomes covered by the tutorial, override all ten files listed by Microsoft. If you omit a biome file, that biome keeps its normal village behavior. This makes the pack useful for partial changes as well: for example, you can leave desert villages enabled while blocking villages in plains and taiga.
A complete block means checking the entire list rather than removing the component from only the biome where you usually build. Villages can appear far from spawn in any covered biome whose definition still contains the component. Make a checklist before editing so a forgotten file does not look like a failed pack later.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →2. Build the pack’s file layout
The example pack contains a manifest.json at its root and a biomes directory containing copies of the target biome definitions. Start with the biome JSON files from the Bedrock release you are actually using; do not mix files from another release.
The complete vanilla-world inventory in Microsoft’s tutorial is:
| Biome definition file | Village coverage |
|---|---|
cold_taiga.biome.json |
Cold taiga |
cold_taiga_hills.biome.json |
Cold taiga hills |
desert.biome.json |
Desert |
ice_plains.biome.json |
Ice plains |
meadow.biome.json |
Meadow |
plains.biome.json |
Plains |
savanna.biome.json |
Savanna |
sunflower_plains.biome.json |
Sunflower plains |
taiga.biome.json |
Taiga |
taiga_hills.biome.json |
Taiga hills |
The manifest identifies the behavior pack to Minecraft. Use the manifest format and identifiers required by your Bedrock release, then place the copied biome files under the pack’s biomes directory. The exact manifest values are release-specific, so use the current Bedrock behavior-pack documentation rather than copying an old manifest unchanged.
Keep the original filenames and directory names exactly. A correctly edited file in the wrong folder is effectively invisible to the override system. Likewise, a pack that contains only a manifest but no matching biome definitions cannot change village generation.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall3. Remove the village component, and nothing else
Open each copied biome file and locate its village component. A typical entry looks like this:
"minecraft:village_type": {
"type": "taiga"
}Delete the complete component block, including its property and surrounding comma as required for valid JSON. Do not delete unrelated climate, mob, surface, or feature definitions. The resulting file should remain valid JSON and otherwise match the current vanilla definition.
Repeat the edit for every biome you intend to cover. Removing the block from only one file does not create a world-wide switch: villages can still generate in any covered biome whose definition retains minecraft:village_type.
JSON punctuation is a common failure point. If the village component appears between two other properties, remove the comma that would otherwise leave invalid syntax; if it is the final property, remove the preceding comma as appropriate. Validate each file before packaging, and avoid reformatting or rewriting unrelated fields.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →4. Package and activate the behavior pack
- Keep the pack root,
manifest.json,biomesfolder, and edited JSON files together. - Package the folder as an
.mcpack, or copy it into the Bedrock behavior-packs directory using the method supported by your platform. - In Minecraft, open Play → Create New World → Behavior Packs.
- Find the pack under available behavior packs and activate it for the world.
- Create the world only after the pack appears in the active list. Generate a fresh test area and verify that the expected biomes no longer produce villages.
Applying the pack before world creation gives the cleanest result because no village-containing chunks exist yet. If you are testing on an existing world, travel to terrain that has never been generated; villages in explored terrain are not removed.
Test with a disposable world first. A small test lets you confirm that the pack loads, the intended biomes are covered, and unrelated biome behavior remains intact before you commit a long-term survival save to the change.
5. Keep the files maintained
Microsoft warns that biome overrides need maintenance as Minecraft releases change. A game update can add, remove, or alter fields in the vanilla biome definitions. After an update, obtain the definitions for that release, reapply only the component removal, and test the pack in a disposable world before relying on it in a long-running save.
If the pack fails to load, check that every edited file is valid JSON, filenames match the originals exactly, the pack manifest is accepted by your release, and the files are in the expected biomes directory. A missing comma or an outdated definition can prevent the override from taking effect.
Do not assume a pack that worked on one Bedrock version remains safe indefinitely. Keeping a clean copy of the unedited vanilla files makes updates easier: replace the old definitions with current ones, remove the same component again, and retest instead of carrying forward a heavily modified legacy file.
Optional: change village style instead of removing villages
The same component can select an allowed village type. Microsoft’s tutorial lists default, desert, ice, savanna, and taiga. Leave the component in place and change its type value when you want villages to use a different style. Remove the component entirely when the goal is no village generation in that biome.
This option is useful when the design goal is consistency rather than absence. For example, a biome can be assigned one of the listed types instead of inheriting its usual style. It still remains a village-generating biome, so use removal—not a type substitution—when you need villages disabled.
Java Edition: the broad built-in switch
Java’s world-creation screen has a Generate Structures setting. Turning it off is the simplest supported choice, but it is deliberately broad: villages disappear along with temples, monuments, and other generated structures, including stronghold-related generation. Use it only when losing every generated structure is acceptable.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Start creating a new Java Edition world.
- Open the world-generation or advanced settings where Generate Structures is shown.
- Set it to Off.
- Create the world and confirm the setting before investing time in exploration or building.
There is no separate vanilla checkbox for “villages off, everything else on.” The built-in switch cannot express that narrower request.
Because the switch is selected during world creation, it is best suited to a new map. It is not a cleanup operation for a save that already contains villages, and it cannot selectively target one biome or one structure family.
Rank #4
- Play and share with friends on console, mobile and Windows 10
- discover community creations in the new in-game store
- access new mini games and game modes through servers
Java Edition: keep other structures with a datapack
Java world generation is data-driven. World settings and enabled datapacks feed registries that describe structures, structure sets, and the biomes in which structures may appear. To remove villages selectively, a datapack must remove village entries from the relevant biome structure tags or adjust the village structure-set data for the exact Java release you are running.
The selective approach preserves the principle behind the reader’s usual request: change only village generation and leave entries for temples, monuments, and other structures alone. It is more precise than Generate Structures: Off, but it requires inspecting the release’s own data rather than relying on a universal folder recipe.
Why release matching matters
Java’s directory names, identifiers, registry contents, and datapack format are version-sensitive. A tutorial written for one release can silently do nothing in another, or produce a datapack that the game rejects. Mojang’s release documentation records continuing changes to configured structures and datapack/world-generation data, so treat an example as a starting point only after comparing it with that release’s vanilla data.
Version matching includes the full release number, not just the major series. A pack should state the release it targets, and its pack format and identifiers should be checked against that installation. If a guide omits its target version, do not assume its paths or tag names are portable.
Safe selective-removal workflow
- Record the exact Java version. Include the full release number, not merely “Java Edition.”
- Start from matching vanilla data. Use that release’s data or a datapack template explicitly built for it. Do not transplant folders or identifiers from an unrelated version.
- Change only village data. Remove village entries from the appropriate biome structure tags or adjust the village structure-set data; leave entries for temples, monuments, and other structures untouched.
- Install and validate the datapack. Enable it for a test world first and inspect the game’s datapack or world-load feedback for errors.
- Generate the world, or use only unvisited chunks. The change controls future generation, not terrain already saved in the region files.
- Keep a backup. A malformed datapack can prevent a world from loading. Preserve an untouched copy so you can remove the pack or restore the save.
Because the exact paths and identifiers depend on the release, a reliable datapack guide must name your version before giving file-level instructions. If a template does not state which release it targets, assume it is unsafe to copy verbatim.
Recommended Free Tools
Make one narrowly scoped change at a time. Removing unrelated structure entries while experimenting makes it difficult to tell whether villages were disabled successfully or whether the pack simply disabled more generation than intended. A test world also gives you a safe place to check load messages before touching a valuable save.
What happens to a world you have already explored?
Generation rules are evaluated when Minecraft creates a chunk. A village saved in an explored chunk remains part of that chunk even after you enable a behavior pack or datapack. You can still use the pack for terrain beyond the explored boundary, but the transition will not erase existing buildings.
- For a guaranteed village-free map, create a new world with the Bedrock pack active or the Java setting/datapack ready from the start.
- For an established map, identify an ungenerated area and keep the rule enabled before entering it.
- If you require existing villages removed, use a separate world-editing or manual demolition process; generation controls alone do not perform that job.
Do not use a nearby unexplored-looking location as proof that old chunks were regenerated. Once Minecraft has saved a chunk, changing generation data does not recalculate it. Test well beyond the known exploration boundary, and remember that newly generated terrain can still contain villages if even one relevant Bedrock biome or Java structure entry was left unchanged.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshooting by symptom
| Symptom | Likely cause | What to check |
|---|---|---|
| Bedrock villages still appear in new terrain | Not every village-generating biome was overridden, or the pack was not active | Confirm the active-pack list, verify filenames and folder placement, and check all ten files if you want complete vanilla coverage |
| Bedrock pack will not load | Invalid JSON, outdated manifest, or a definition copied from another release | Validate JSON syntax, rebuild the manifest for the installed release, and recopy current biome definitions |
| Villages remain near an old base | Those chunks were generated before the change | Test in genuinely unvisited terrain; existing villages are not removed |
| Java temples and villages both disappear | Generate Structures was turned off | Use a selective, version-matched datapack if other structures must remain |
| Java datapack has no visible effect | Wrong release identifiers or the wrong tag/structure-set data was edited | Compare the pack with that version’s vanilla data and test in newly generated chunks |
| Java world refuses to load after installing a pack | Datapack format or JSON error | Restore the backup, remove the pack, then correct it against the target release before retrying |
When diagnosing Bedrock, first establish whether the pack itself is active, then inspect coverage and JSON. When diagnosing Java, establish the exact release, confirm the datapack is accepted, and only then investigate whether you edited the correct village tag or structure-set data. In either edition, verify the test location is in a newly generated chunk.
Practical decision checklist
- Bedrock and no villages anywhere: prepare the behavior pack, remove
minecraft:village_typefrom all ten listed biome files, activate it before creating the world, and maintain it after updates. - Bedrock and only some biomes changed: override only those biome files; omitted files retain normal village generation.
- Java and no structures at all: turn Generate Structures off when creating the world.
- Java villages off but other structures on: build or obtain a datapack matched to the exact release and edit village tags or structure-set data only.
- Any edition with an existing save: expect villages in generated chunks to remain and test the rule in new terrain.
Back up a save before adding or replacing generation data. Keep a note of the edition, full version, pack name, and the date you tested it. That record makes it easier to rebuild a Bedrock override or find a compatible Java datapack after a game update.
Bottom line
Bedrock requires a biome override that removes minecraft:village_type; Java’s simple switch removes every generated structure, while selective village removal requires version-specific datapack work. Configure either solution before generating the world whenever a genuinely village-free map is the goal.
Frequently Asked Questions
Can I disable villages but keep temples, monuments, and other structures?
Yes. In Bedrock, remove minecraft:village_type only from the biome files you want to change. In Java, do not use Generate Structures: Off; use a datapack matched to your exact release and remove village entries from the relevant biome structure tags or village structure-set data.
Will a Bedrock behavior pack remove villages that already exist?
No. Microsoft states that the override does not remove existing villages in previously generated chunks. It affects new chunks generated after the pack is active; create a new world for the cleanest result.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How many Bedrock biome files must I override for complete vanilla coverage?
Microsoft’s tutorial lists ten: cold_taiga, cold_taiga_hills, desert, ice_plains, meadow, plains, savanna, sunflower_plains, taiga, and taiga_hills, each with the .biome.json filename.
Can I disable villages in only one Bedrock biome?
Yes. Include and edit only that biome’s definition. Any biome file you omit keeps its normal minecraft:village_type behavior.
Is Java’s Generate Structures option villages-only?
No. It is a broad world-creation setting that disables villages along with temples, monuments, and other generated structures, including stronghold-related generation.
Why did my Java datapack work in one version but not another?
Java’s datapack format, directory names, identifiers, registry contents, and structure data can change between releases. Rebuild or verify the pack against the exact full version you are running, and test it in newly generated chunks.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsCan I change a Bedrock village’s style instead of deleting it?
Yes. Leave the component in place and use one of Microsoft’s listed village types—default, desert, ice, savanna, or taiga. Remove the component only when you want no village generation in that biome.
The Bottom Line
Bedrock: remove minecraft:village_type from the relevant biome overrides and activate the behavior pack before world creation. Java: use Generate Structures: Off only if all structures may disappear; otherwise use a datapack matched to the exact release. Existing chunks keep their villages.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
