What .mcaddon, .mcpack, and .mctemplate Files Actually Are

Despite having specialized file extensions, .mcpack, .mcaddon, and .mctemplate files are standard ZIP archives compressed using the normal DEFLATE algorithm. They are not encrypted, compiled, or proprietary binary formats. Operating systems associate these custom extensions with the Minecraft Bedrock executable. When a player opens one of these files, the operating system hands the file path to Minecraft, which then extracts the archive into the appropriate local game storage directory.

Because they are standard ZIP files, you can inspect or create them using any regular compression utility without needing special software. If you rename an existing .mcpack file to end in .zip, you can extract and view its contents immediately. Conversely, to build one from your development workspace, you compress your files into a standard .zip archive and then rename the file extension. Note that you cannot rename a .rar or .7z archive to a Minecraft extension; the game's internal extractor only understands the ZIP format.

An .mcpack file is designed to distribute a single, standalone pack. This is what you use when sharing a pure resource pack (like a texture overhaul or UI tweak), a standalone behavior pack, or a skin pack. When Minecraft imports an .mcpack, it looks at the manifest.json file inside the archive, reads the module type (`resources`, `data`, `script`, or `skin_pack`), and copies the extracted contents into the corresponding game directory.

The most important structural rule when creating an .mcpack is that the `manifest.json` file should sit directly at the root of the ZIP archive, alongside folders like `entities/`, `textures/`, or `blocks/`, and your `pack_icon.png`. While some versions of Minecraft can recover if you accidentally zip the parent folder (leaving `manifest.json` one folder deep), doing so is unreliable across different platforms and often causes silent import failures when that .mcpack is later bundled inside an .mcaddon. Always select the contents of your pack folder and zip them directly, rather than zipping the pack folder itself.

During the import process, Minecraft reads the `header.uuid` and `header.version` fields in the manifest. If a pack with the exact same UUID already exists in the player's storage with an equal or higher version number, Minecraft will refuse to overwrite it and will display a duplicate pack error. If you are distributing an update to an existing pack, you must keep the UUIDs identical so existing worlds maintain their link to the pack, but you must increment the version array in both the `header` and `modules` sections.

{
  "format_version": 2,
  "header": {
    "name": "pack.name",
    "description": "pack.description",
    "uuid": "569043c1-6d4b-4899-9f7e-325120545601",
    "version": [1, 0, 0],
    "min_engine_version": [1, 20, 80]
  },
  "modules": [
    {
      "type": "data",
      "uuid": "a329980c-4012-4035-8243-509238192831",
      "version": [1, 0, 0]
    }
  ],
  "dependencies": [
    {
      "uuid": "f8940219-8392-4c11-b831-093817263541",
      "version": [1, 0, 0]
    }
  ]
}

Full add-ons almost always require both a behavior pack (to define entity logic, loot, blocks, or scripts) and a resource pack (to define models, textures, sounds, and animations). Asking players to download and install two separate .mcpack files often leads to them forgetting to install one half. The .mcaddon format solves this by acting as a container archive that holds multiple packs at once.

Unlike an .mcpack, an .mcaddon file does not have a `manifest.json` at its root. Instead, the root of the .mcaddon ZIP archive contains your behavior pack and resource pack as separate items. There are two valid ways to structure the inside of an .mcaddon: you can place two separate `.mcpack` files inside the root of the archive, or you can place two uncompressed subfolders (for example, `my_addon_bp/` and `my_addon_rp/`) at the root, with each subfolder containing its own `manifest.json` directly inside it.

Using two subfolders or two `.mcpack` files at the root both work reliably across platforms, though packaging two `.mcpack` files into the `.mcaddon` ZIP is clean and prevents accidental loose files at the root. To make the two packs recognize each other in-game, you should declare the resource pack's `header.uuid` inside the behavior pack's `dependencies` array (and vice versa). When linked this way, activating the behavior pack on a world automatically activates the matching resource pack.

An .mctemplate file is used when your creation relies on a pre-built map—such as an adventure map, a custom survival spawn, or a minigame arena—rather than being applied to a random seed. While a standard `.mcworld` file simply imports a saved game directly into the player's active worlds list, an `.mctemplate` installs into the game's `world_templates` folder. It then appears alongside official templates in the 'Create New World' screen, allowing the player to generate fresh, unspoiled copies of your world whenever they want.

At the root of an .mctemplate archive, you will find all the standard files of a Bedrock world save: `level.dat`, `levelname.txt`, the `db/` folder (which stores chunk and entity data in LevelDB format), and `world_icon.jpeg` (note that world icons must be JPEG files, unlike pack icons which are PNGs). However, what makes a template distinct from a plain `.mcworld` is that an `.mctemplate` requires its own `manifest.json` at the root of the world folder, using a module type of `world_template`.

To make an .mctemplate completely self-contained, you can embed your add-on packs directly inside the template archive. Inside the root of the world folder, you include `world_behavior_packs.json` and `world_resource_packs.json` (which list the active pack UUIDs and versions), alongside the actual pack folders placed inside `behavior_packs/` and `resource_packs/` subdirectories. In the template's `manifest.json`, setting `lock_template_options` to `true` will warn players if they attempt to unlock and alter the world's settings, helping prevent them from accidentally breaking your custom map rules.

{
  "format_version": 2,
  "header": {
    "name": "template.name",
    "description": "template.description",
    "uuid": "81920384-7c12-4091-8273-918273645019",
    "version": [1, 0, 0],
    "lock_template_options": true,
    "base_game_version": [1, 20, 80]
  },
  "modules": [
    {
      "type": "world_template",
      "uuid": "10293847-5610-4928-a817-293847561029",
      "version": [1, 0, 0]
    }
  ]
}

Before compressing your folders for release, it is good practice to clean out development artifacts. Operating systems frequently generate hidden metadata files inside folders—such as `.DS_Store` and `__MACOSX` on macOS, or `Thumbs.db` and `desktop.ini` on Windows. Similarly, if you use Git for version control, a `.git` folder may sit in your project root. While these rarely stop a pack from importing, they bloat the file size and can trigger warnings in strict validation tools. Exclude them when building your ZIP archive.

Pay close attention to file path casing and length. Windows treats `textures/items/My_Sword.png` and `textures/items/my_sword.png` as the same file, meaning a typo in your JSON might still work on your PC during testing. However, ZIP archives, Android, iOS, and consoles often treat paths داخل archives with strict case sensitivity. Always use lowercase for all folder and file names inside your packs. Additionally, keep your folder hierarchy reasonably shallow; deeply nested folders combined with long file names can exceed the maximum path length limit when Minecraft extracts the pack into its deep internal `com.mojang` directory structure on Windows or mobile.

Applies to all modern versions of Minecraft Bedrock Edition (1.16.0 and newer for format_version 2 manifests). No experimental toggles are required to package or import these archive formats.

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