Applying a Pack to an Existing World Safely

When you activate a behavior pack or resource pack on a world through the game UI, Minecraft does not always rely on the global `development_behavior_packs` or `behavior_packs` folders to run that world later. For retail packs (imported via `.mcpack` or `.mcaddon`), the game copies the entire pack directory into a `behavior_packs` or `resource_packs` folder inside the specific world's save folder. Development packs remain linked to the `development_*` folders, meaning edits to those files immediately affect the world on next load.

Beyond the physical files, the world tracks which packs are active using two JSON files located in the root of the world save directory: `world_behavior_packs.json` and `world_resource_packs.json`. These files act as an ordered load list, referencing each pack solely by its header UUID and version array. If a pack is listed in these JSON files, the world expects to find a matching manifest either inside its own local pack folders or in the global `com.mojang` directories.

Removing or altering a pack that is already bound to a world has permanent consequences for loaded chunks. When you load a chunk that previously contained a custom block whose definition is now missing, the engine replaces that block with an `info_update` placeholder block (often called the 'update!' dirt block). If a custom entity's behavior definition is missing when its chunk ticks, the entity is silently deleted from the world database and will not return even if you re-apply the pack later.

Never apply an untested pack—or a major version update of an existing pack—directly to your primary world copy. Before touching the pack settings, create a clean duplicate of the world so you have an untouched fallback if a loot table, terrain feature, or script misfires.

The fastest safe method inside the game client is to open the Edit World screen for your target save, scroll to the bottom of the General tab, and select Copy World. This generates a fresh directory inside `minecraftWorlds` with a new folder name, preserving all LevelDB chunk data, player inventories, and active pack configurations. Apply your new pack only to this copy first.

For production worlds or dedicated servers, you should also export a physical archive. On desktop platforms, use the Export World button at the bottom of the Edit World menu to generate a standalone `.mcworld` file (which is a standard ZIP archive containing the world root). If you are backing up the raw folder from `minecraftWorlds` manually through your operating system's file manager, you must fully close Minecraft or stop the dedicated server process first. Copying the `db` folder while the game holds an open file lock on the LevelDB database frequently results in truncated `.ldb` or `MANIFEST` files, rendering the backup unreadable.

While you can enable packs through the Edit World interface, managing them directly through `world_behavior_packs.json` and `world_resource_packs.json` is safer when working with dedicated servers, realm exports, or fragile multi-pack load orders. Each file contains a simple JSON array of objects, where each object points to the `uuid` and `version` defined in the `header` block of your pack's `manifest.json`.

The order of objects in the array dictates pack priority. The pack at index `0` (the top of the file) has the highest priority; if two packs override the same vanilla file, such as `entities/player.json`, the pack higher in this array wins. When adding your pack to an existing world that already uses other add-ons, place your entry carefully so you do not accidentally overwrite—or get overwritten by—another pack's definitions.

[
  {
    "pack_id": "8f4e2b10-5c3a-4b9e-9a1d-2e6f7c8d9a0b",
    "version": [1, 0, 0]
  }
]

When a world already has your pack active and you want to push an update to it, the golden rule is to preserve the `header.uuid` in your `BP/manifest.json` and `RP/manifest.json`. Minecraft identifies your pack exclusively by this UUID. If you generate a brand-new UUID for an update and apply it, the world treats the old version as missing and the new version as a separate add-on, which can cause `world_behavior_packs.json` to hold duplicate entries or fail to resolve dependencies.

Equally important are the custom identifiers inside your pack (`identifier` fields in blocks, items, and entities). Once a block like `my_pack:copper_pipe` is placed in a chunk, that exact string is serialized into the LevelDB chunk data. Renaming the identifier in a later pack version will turn every already-placed instance in the world into an `info_update` block.

When updating a pack that resides in `development_behavior_packs`, you do not need to increment the version number in the manifest for the world to see your changes; simply save your files and reload the world (or run `/reload` for scripts and functions). However, if you package the update as an `.mcpack` for distribution or import it into a world that caches packs locally in its own `behavior_packs` folder, you should bump the `header.version` array (for example, from `[1, 0, 0]` to `[1, 0, 1]`) and update the matching version array in `world_behavior_packs.json` so the engine replaces the cached copy.

{
  "format_version": 2,
  "header": {
    "name": "Existing World Expansion BP",
    "description": "Safe incremental update keeping the original UUID",
    "uuid": "8f4e2b10-5c3a-4b9e-9a1d-2e6f7c8d9a0b",
    "version": [1, 0, 1],
    "min_engine_version": [1, 20, 80]
  },
  "modules": [
    {
      "type": "data",
      "uuid": "3a1b2c4d-5e6f-4a8b-9c0d-1e2f3a4b5c6d",
      "version": [1, 0, 1]
    }
  ],
  "dependencies": [
    {
      "uuid": "7c9d8e0f-1a2b-4c3d-8e5f-6a7b8c9d0e1f",
      "version": [1, 0, 1]
    }
  ]
}

Applying a behavior pack to a world that has already been explored affects explored and unexplored territory differently. Entity spawn rules (`BP/spawn_rules/`), loot tables (`BP/loot_tables/`), trading tables, and scripts begin working immediately across the entire world, including the chunks around the player's existing base, as soon as the world finishes loading.

World generation content—specifically `BP/features/` and `BP/feature_rules/` such as custom underground ores, surface structures, or custom trees—only runs during the initial generation phase of a chunk. Chunks that have already been visited and saved to the world's `db/` folder will never retroactively generate your new ores or structures. Players will have to travel to previously unvisited chunks for new features to appear.

Also keep in mind that adding ANY behavior pack to a survival world immediately and permanently disables Xbox Live achievements for that world save. The engine writes a flag into `level.dat` when a behavior pack is activated, and removing the pack later will not re-enable achievements unless you restore from a pre-pack backup. Pure resource packs (`RP`) do not disable achievements.

Two settings inside your pack and world configuration can permanently lock an existing world so it cannot be downgraded or played normally without experimental flags. The first is the `min_engine_version` field in `BP/manifest.json`, coupled with simply opening the world in a newer client. Whenever a world is opened and saved in a newer version of Minecraft Bedrock, `level.dat` updates its internal version tag, preventing older game clients from opening that save.

The second is enabling experimental toggles (such as Beta APIs or upcoming creator features) in the world's Experiments menu. The moment you turn an experimental toggle on, the game forces you to either create a copy of the world or convert the world into an experimental save. Once that flag is written to `level.dat`, it cannot be turned back off through the in-game UI.

If your pack relies on stable features—such as standard entity components, `minecraft:destructible_by_mining` on blocks, or stable `@minecraft/server` API versions—do not enable experimental toggles on a world you care about keeping long-term. Always test experimental features on a disposable copy.

Applies to all modern Minecraft Bedrock versions (1.16.0 through 1.21+). Manifest format_version 2 is stable and requires no experimental toggles unless your pack specifically uses Beta script modules or experimental components.

Read out of the game itself, so the ids match the version you are building for.