Pack Folder Structure Reference

Every valid pack must have a manifest.json file sitting directly in its root folder. If you zip your pack with an extra wrapper folder around the root, Minecraft will fail to detect the manifest during import or directory scanning. Alongside the manifest, you can place a square PNG image named pack_icon.png, which displays in the world settings and storage menus.

The manifest defines the pack's identity via unique UUIDs and tells the engine what kind of files to expect inside through the module type. A Behavior Pack uses the data module type (and optionally script for the Script API), while a Resource Pack uses the resources module type.

{
  "format_version": 2,
  "header": {
    "name": "Example Behavior Pack",
    "description": "Server logic and definitions",
    "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]
    }
  ]
}

Behavior Packs control how the world operates. For most directories in a Behavior Pack, the engine recursively scans all subfolders and ignores the actual filenames, caring only about the identifier declared inside the JSON. For example, you can organize BP/entities/ into subfolders like BP/entities/hostile/ and BP/entities/passive/ without changing how the game loads them.

There are two strict exceptions to this rule: functions and structures. In both BP/functions/ and BP/structures/, the relative folder path and the file name directly determine the identifier you type in commands or structure blocks. A file at BP/functions/arena/reset.mcfunction is called in-game as function arena/reset.

Resource Packs handle everything the player sees and hears. While directories like RP/entity/, RP/models/, and RP/render_controllers/ allow you to organize JSON files into arbitrary subfolders because they rely on internal identifiers, asset folders like RP/textures/ and RP/sounds/ rely strictly on file paths.

Furthermore, several critical registry files must sit at exact, hardcoded paths and are not inside their own dedicated folders. For instance, blocks.json and biomes_client.json sit in the root of the Resource Pack, and sound_definitions.json must sit inside RP/sounds/.

In a Resource Pack, blocks and items rarely point directly to a PNG file path in their main definition files. Instead, they use a shortname (an alias) mapped in RP/textures/terrain_texture.json (for blocks) or RP/textures/item_texture.json (for items). This layer of indirection lets the engine stitch all block and item textures into large texture atlases during pack loading.

When writing paths inside these JSON registries—or inside client entity definitions—you must always start from the root of the Resource Pack (textures/...) and omit the .png or .tga file extension. The engine automatically resolves the file format and checks for texture variations.

{
  "resource_pack_name": "example_rp",
  "texture_name": "atlas.terrain",
  "padding": 8,
  "num_mip_levels": 4,
  "texture_data": {
    "example_custom_ore": {
      "textures": "textures/blocks/custom_ore"
    }
  }
}

Inside Minecraft's com.mojang application directory, you will find two pairs of pack folders: behavior_packs / resource_packs, and development_behavior_packs / development_resource_packs. When you double-click a .mcpack or .mcaddon file, Minecraft extracts the contents into the standard behavior_packs and resource_packs folders.

While building an add-on, you should place your working folders inside development_behavior_packs and development_resource_packs instead. When a world uses a pack from the development directories, it links to the pack by UUID rather than copying the entire folder into the world's own db directory. This allows you to edit JSON files, scripts, and textures on your drive and see the changes immediately after reloading the world or running /reload.

Applies to all modern Bedrock Edition versions (1.16.0 through 1.21+). The base folder layout is stable and requires no experimental toggles, though specific features inside folders (like beta Script API modules in BP/scripts/) have their own version and toggle requirements.

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