How to Package & Publish a Minecraft Bedrock Add-on (2026)

The short answer

A .mcpack is a zip archive of one Behavior Pack or Resource Pack. Its manifest.json must sit at the archive root. A .mcaddon is a zip container that can hold the related .mcpack files, allowing players to import the complete add-on together.

Before packaging, preserve the pack UUIDs, increment version arrays, verify Resource Pack dependencies, remove development-only files, and test the release on a profile that has never imported the add-on.

Choose the right release file

• .mcpack: one Behavior Pack, Resource Pack, or other individual supported pack.
• .mcaddon: a container for the complete add-on, commonly one Behavior Pack .mcpack plus one Resource Pack .mcpack.
• .mcworld: a packaged world, useful when the experience depends on a prepared map or template rather than independent packs.

For a normal downloadable add-on with behavior and resources, publish one .mcaddon. Keep the individual .mcpack files as build artifacts for debugging, but avoid making ordinary users guess which file to import first.

Step 1: prepare manifest versions

For updates to the same product, keep the existing header and module UUIDs. Increase the version arrays in both packs and update the Behavior Pack dependency so it requests the new Resource Pack version.

{
  "header": {
    "name": "Ruby Adventures BP",
    "uuid": "KEEP-YOUR-BEHAVIOR-PACK-UUID",
    "version": [1, 2, 0],
    "min_engine_version": [1, 21, 90]
  },
  "modules": [
    {
      "type": "data",
      "uuid": "KEEP-YOUR-BEHAVIOR-MODULE-UUID",
      "version": [1, 2, 0]
    }
  ],
  "dependencies": [
    {
      "uuid": "KEEP-YOUR-RESOURCE-PACK-UUID",
      "version": [1, 2, 0]
    }
  ]
}

Replace the placeholders with the real existing UUIDs. Do not ship placeholder text, and do not generate new UUIDs for a routine update. New UUIDs create a separate pack identity and are a common cause of duplicate imports.

Step 2: create clean staging folders

Copy the release-ready contents into separate staging folders. Keep source art, editor backups, test exports, notes, logs, and build scripts outside the pack archive unless the game needs them.

release-1.2.0/
  staging/
    RubyAdventures_BP/
      manifest.json
      pack_icon.png
      entities/
      items/
      loot_tables/
      recipes/
      scripts/
    RubyAdventures_RP/
      manifest.json
      pack_icon.png
      attachables/
      models/
      sounds/
      texts/
      textures/
  output/

Only include folders your add-on actually uses. The important rule is that every game file has the correct type, name, and location inside its pack.

Step 3: build each .mcpack

Open the Behavior Pack folder and zip its contents, not the parent folder. When the archive is opened, manifest.json should be visible immediately.

RubyAdventures-BP-1.2.0.mcpack
  manifest.json
  pack_icon.png
  entities/
  items/
  loot_tables/
  recipes/

This layout is wrong because it adds an extra directory layer:

RubyAdventures-BP-1.2.0.mcpack
  RubyAdventures_BP/
    manifest.json
    entities/

Repeat the same process for the Resource Pack. Build standard zip archives first, then change only the extension from .zip to .mcpack.

Step 4: combine the packs into .mcaddon

Put the two finished .mcpack files into a new zip archive and rename that outer archive to .mcaddon:

Ruby-Adventures-1.2.0.mcaddon
  RubyAdventures-BP-1.2.0.mcpack
  RubyAdventures-RP-1.2.0.mcpack

Use a stable, readable file name with product and version. Avoid names such as final-final-fixed2.mcaddon; they make support requests and update comparisons needlessly difficult.

Step 5: test like a new player

1. Back up any worlds that use the development version.
2. Use a separate Minecraft profile or device with no copy of the add-on.
3. Open the .mcaddon and confirm both packs import successfully.
4. Create a new world and activate the Behavior Pack.
5. Confirm the linked Resource Pack activates as intended.
6. Test core items, recipes, mobs, sounds, scripts, and multiplayer.
7. Close and reopen Minecraft, then reload the world.
8. Install the previous public release, import the update, and test the upgrade path.

A development world proves your files can work. A fresh-profile import proves your release archive contains everything another player needs.

Build a useful release page

Give players enough information to decide, install, and troubleshoot without guessing:

• Exact add-on name and version.
• Supported Minecraft Bedrock versions and tested platforms.
• A concise feature summary with real screenshots or gameplay media.
• Installation steps and whether experiments are required.
• Compatibility notes, known conflicts, and multiplayer expectations.
• A changelog for the current release.
• Credits, license, support route, and safe download source.

Do not claim support for a platform you did not test. Clear limitations build more trust than a vague promise that the add-on works everywhere.

Release updates without duplicate packs

• Keep the same pack and module UUIDs.
• Increment header and module versions consistently.
• Update dependency versions between paired packs.
• Keep names stable enough for players to recognize the product.
• Test import over the previous public version.
• Document world-breaking or experimental changes before download.

If your users already have duplicate entries, follow the duplicate Bedrock packs guide before testing another update.

Final release preflight

• All JSON parses and the Content Log is clean.
• No placeholder UUIDs, titles, descriptions, or test identifiers remain.
• Pack icons and localized names display correctly.
• Behavior and Resource Pack versions agree.
• The archive has no extra parent folder.
• The file name includes the real release version.
• The download opens as an archive and imports as an add-on.
• A checksum or retained release copy exists for support and rollback.

Why a packaged Bedrock add-on fails

Minecraft says the import failed

Open the archive and check that manifest.json is at the pack root. Validate manifest JSON, UUID format, module type, and version arrays.

Only one of the two packs imports

Open each .mcpack independently. Check the failing pack's manifest and make sure the outer .mcaddon contains both complete files.

The Resource Pack does not activate

Verify the Behavior Pack dependency uses the Resource Pack header UUID and exact version. Check that the Resource Pack itself imported successfully.

The update creates a duplicate

Compare pack header and module UUIDs with the previous public release. Preserve identity and change version arrays, not UUIDs.

The add-on works only on the creator's PC

Look for missing files, case mismatches, absolute assumptions, development-only dependencies, or a Resource Pack that was active separately in the creator's test world.

Frequently asked questions

Can I create .mcaddon files with Blockbench?

Yes. Bedrock creator plugins can export .mcaddon files. Still inspect and test the exported manifests and archive structure so future updates keep the same pack identity.

Should I include both packs separately too?

Keep them in your release records and offer them only when advanced users or support workflows need separate imports. The main download should normally be the complete .mcaddon.

Can I rename a .zip without recompressing it?

Yes, when the contents are already a standard zip archive with the correct internal structure. Changing the extension does not fix an extra folder level or an invalid manifest.

Official sources checked

• Microsoft Learn: Minecraft File Extensions
• Microsoft Learn: Comprehensive List of Add-On Pack Contents
• Microsoft Learn: Add-on Pack Foundations
• Microsoft Learn: Blockbench Export as MCAddon

Continue building

• Minecraft Bedrock manifest.json Guide
• Bedrock Add-on Debugging Checklist
• Fix Duplicate Packs in Minecraft Bedrock
• How to Install Add-ons in Minecraft Bedrock