Downloading and Using Vanilla Example Packs

When you install Minecraft Bedrock Edition, you cannot simply open the program directory and read every vanilla file. Many textures are compiled into binary formats, UI definitions are packed away, and certain behavior files are inaccessible or difficult to locate depending on your operating system. To make add-on development possible without reverse-engineering the game, Mojang publishes clean copies of the default Resource Pack and Behavior Pack.

These archives are snapshots of the vanilla game's data-driven definitions for a specific release. Inside the Resource Pack template, you get standard PNG textures, geometry JSON files, render controllers, client entity definitions, animation files, and sound mappings. Inside the Behavior Pack template, you get server entity definitions, loot tables, spawn rules, trading tables, and recipes. You do not get hardcoded C++ logic—blocks and items that have not yet been migrated to purely data-driven JSON inside the vanilla packs will not appear in full detail—but almost every mob, recipe, and loot table in the game is there in plain text.

In older versions of Bedrock, Mojang distributed the vanilla Resource and Behavior packs as direct `.zip` downloads tied to major update notes. Today, all official example files are hosted and maintained in the official Minecraft Bedrock Samples repositories on GitHub. There are two main places you will pull from: the general `bedrock-samples` repository, which holds the full vanilla resource and behavior files for the current retail release (and a separate branch for Preview/Beta releases), and the `minecraft-scripting-samples` repository, which contains minimal starter templates for TypeScript and JavaScript add-ons.

When you download the main repository archive, you will receive a single large `.zip` file containing several folders at the root level, including `resource_pack` and `behavior_pack`, alongside a `documentation` folder and various smaller feature samples. You should extract this archive into a dedicated reference folder on your hard drive, completely separate from your active Minecraft `com.mojang` directory. Keeping a clean, untouched copy of the vanilla files on your computer allows you to search across thousands of JSON files using your code editor whenever you need to see how Mojang structured a specific component.

The most common mistake new creators make after downloading the example packs is importing the entire vanilla template into Minecraft and activating it on a world. You should never use the full vanilla example pack as the base for your own project. A complete vanilla resource pack contains thousands of textures and definitions; loading all of them as an active add-on wastes memory, slows down world loading, and guarantees that your pack will break future updates by overwriting new vanilla changes with older files.

Minecraft Bedrock uses a layered override system. When your custom pack is active, the game loads your files first and falls back to the built-in vanilla assets for anything you did not include. If you only want to change the creeper's explosion timer, your behavior pack should contain only `manifest.json`, `pack_icon.png`, and `entities/creeper.json`. Treat the downloaded example packs strictly as a read-only library: copy out the single file you want to study or override, place it into the matching folder path inside your own small pack, and leave the rest behind.

If you do copy the folder structure or `manifest.json` from an example pack to start your own project, you must immediately replace the `uuid` fields inside the manifest. The official example packs ship with fixed, hardcoded UUIDs that Minecraft recognizes as the base vanilla packs. If you leave those UUIDs untouched, the game will either refuse to import your pack because it detects a duplicate, or it will confuse your custom pack with the internal vanilla assets.

Below is a clean, minimal `manifest.json` for a Behavior Pack. Instead of using the bloated manifest from the vanilla download—which often includes legacy modules or internal version locks—strip your file down to this structure and generate two brand-new Version 4 UUIDs for the `header` and `modules` blocks.

{
  "format_version": 2,
  "header": {
    "name": "My Custom Behavior Pack",
    "description": "A clean pack built using vanilla reference files.",
    "uuid": "00000000-0000-4000-8000-000000000001",
    "version": [1, 0, 0],
    "min_engine_version": [1, 20, 80]
  },
  "modules": [
    {
      "type": "data",
      "uuid": "00000000-0000-4000-8000-000000000002",
      "version": [1, 0, 0]
    }
  ]
}

To see how the example packs are used in practice, consider modifying a vanilla pig's movement speed and health. First, open your extracted `behavior_pack` reference folder and locate `entities/pig.json`. Copy that single file into the `entities/` folder of your own development behavior pack inside `development_behavior_packs`. Because your file shares the exact `minecraft:pig` identifier and sits in a pack loaded above the vanilla data, your version completely replaces the default pig definition.

Once copied, you can inspect and edit the components. You do not need to guess what component controls health or how breeding items are listed; they are already written out in the vanilla file. You can also strip down the file or create a brand-new entity by changing the `identifier` from `minecraft:pig` to your own namespace, such as `my_pack:fast_pig`.

{
  "format_version": "1.20.0",
  "minecraft:entity": {
    "description": {
      "identifier": "minecraft:pig",
      "is_spawnable": true,
      "is_summonable": true,
      "is_experimental": false
    },
    "components": {
      "minecraft:type_family": {
        "family": [ "pig", "mob" ]
      },
      "minecraft:health": {
        "value": 20,
        "max": 20
      },
      "minecraft:movement": {
        "value": 0.35
      },
      "minecraft:movement.basic": {},
      "minecraft:navigation.walk": {
        "can_path_over_water": true,
        "avoid_water": true,
        "avoid_damage_blocks": true
      },
      "minecraft:jump.static": {},
      "minecraft:physics": {}
    }
  }
}

Beyond copying files to override them, the example packs are the most reliable documentation available for Bedrock's JSON schemas. Official written documentation sometimes lags behind game updates or omits subtle interactions between components. The vanilla behavior and resource packs, however, are the exact files running inside the current version of Minecraft. If a mob performs an action in-game through JSON, the exact syntax is sitting in the example pack.

Open the root folder of the extracted `bedrock-samples` archive in a code editor like Visual Studio Code and use the global file search feature. If you want to know how `minecraft:interact` is formatted, search for that exact string across the `behavior_pack/entities` folder; you will immediately see how sheep handle shears, how cows handle buckets, and how villagers handle trading. Similarly, searching the `resource_pack` folder for a sound identifier shows you how `sounds.json` links to `sound_definitions.json`, giving you working code you can adapt without guessing field names.

Applies to all retail and Preview versions of Minecraft Bedrock Edition. Always download the branch or release tag that matches your target game version (main branch for stable retail, preview branch for Beta/Preview). No experimental toggles are needed to inspect or override standard vanilla files.

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