What's Inside a .mcaddon File? A Complete Breakdown

You've downloaded a .mcaddon file, double-clicked it, and Minecraft imported it. But have you ever wondered what's actually inside that file? What makes a Minecraft Bedrock mod tick?

Let's crack one open and look at every piece. By the end of this article, you'll understand exactly how Bedrock add-ons work at a structural level.

It's Just a Zip File

Seriously. A .mcaddon file is a .zip archive with a different extension. If you rename cool_mod.mcaddon to cool_mod.zip and extract it, you'll see regular folders and files inside.

When you extract it, you'll typically find one or two folders:

• A Behavior Pack folder (sometimes abbreviated BP) — This controls game logic: what mobs do, how items work, crafting recipes, loot drops, and scripts.
• A Resource Pack folder (sometimes abbreviated RP) — This controls appearance: textures, models, sounds, animations, and UI elements.

Some mods only have a behavior pack (if they don't need custom visuals). Some have both. Let's explore what's inside each one.

The Manifest: manifest.json

Every pack — both behavior and resource — starts with a manifest.json file in its root folder. This is the pack's ID card. Minecraft reads this first to understand what the pack is.

The UUID is critical. It's how Minecraft tells packs apart. If two packs have the same UUID, Minecraft thinks they're the same pack and will show "Duplicate Pack Detected." Every pack needs a unique UUID.

Inside the Behavior Pack

The behavior pack is where the real action happens. Here are the folders you might find:

entities/

This folder contains JSON files that define custom mobs (or modify vanilla ones). Each file describes an entity's entire behavior: its health, movement speed, what it attacks, what it drops when killed, how it spawns, and what special abilities it has.

Entity files use a component system. Instead of writing code, you attach pre-built components to an entity. Want it to explode? Add minecraft:explode. Want it to shoot arrows? Add minecraft:shooter. Want it to follow the player? Add minecraft:behavior.follow_owner.

This component system is what makes Bedrock modding accessible — you're assembling behaviors from a menu rather than programming them from scratch.

items/

Custom item definitions. Each JSON file describes an item's properties: what category it's in, whether it's food, a weapon, or a tool, its damage values, durability, and any special behaviors. Items can reference textures, have custom use animations, and define cooldown timers.

blocks/

Custom block definitions. Similar to items but for blocks you can place in the world. You can define hardness, what tools mine them faster, whether they emit light, their geometry (shape), and what happens when you interact with them.

recipes/

Crafting recipes, smelting recipes, and brewing recipes. Each JSON file describes the input items and their arrangement (for shaped recipes) or just the required ingredients (for shapeless recipes), plus the output item.

loot_tables/

What drops when a mob dies, a chest generates, or a block breaks. Loot tables support weighted random drops, conditions (like "only drops if killed by player"), and fortune/looting enchantment bonuses.

spawn_rules/

Controls where and when custom mobs appear in the world. You define the biome, light level, surface type, spawn weight (rarity), and group size. This is what makes your custom zombie only spawn in deserts at night, or your crystal golem only appear in mountain caves.

scripts/

JavaScript files that use Minecraft's Script API (@minecraft/server). This is where complex game logic lives — things that JSON components can't express. Event listeners, custom commands, game state management, timers, particle effects, and more.

Scripts are the most powerful part of a Bedrock mod. They bridge the gap between "JSON configuration" and "real programming." A script can listen for a player right-clicking an item, then spawn an entity, apply effects, modify blocks, and display text — all in response to a single event.

trading/

Custom villager trading tables. You can create new trade lists for custom NPCs or modify existing villager trades.

dialogue/

NPC dialogue trees. These define conversations that NPCs can have with players, with branching options and responses.

Inside the Resource Pack

The resource pack makes everything look and sound right.

textures/

PNG image files for every custom entity, item, block, and particle. Entity textures are mapped onto 3D models. Item textures are the 16x16 (or larger) icons you see in your inventory. Block textures are applied to each face of the block.

models/

Geometry files (also JSON) that define the 3D shape of entities and blocks. Minecraft's model format uses cubes — you build complex shapes by combining, rotating, and positioning rectangular boxes. Each cube references a portion of the texture file.

animations/

Animation files that define how entities move. Walk cycles, attack swings, idle animations, death sequences — each one describes which bones rotate/translate and by how much, over what timeframe. Animations are also JSON files with keyframe data.

animation_controllers/

State machines that decide which animation plays and when. For example: "If the entity is walking, play walk_animation. If it's attacking, play attack_animation. If it's idle, play idle_animation." These handle transitions between states too.

render_controllers/

Tells the game which texture and geometry to use for an entity, and under what conditions. Entities can have multiple textures (for variants) or swap textures based on state.

sounds/

Custom sound files (usually .ogg or .wav) plus a sound_definitions.json that maps sound names to files and defines properties like volume, pitch, and category.

entity/

Client-side entity definitions. While the behavior pack defines what an entity does, the resource pack's entity files define what it looks like: which model, texture, animations, render controller, and spawn egg appearance to use.

texts/

Language files (en_US.lang and others) that define the display names for your custom items, entities, and blocks. Without these, your items would show up as their internal identifiers (like "blocksmith:shadow_sword") instead of friendly names ("Shadow Sword").

How It All Connects

Here's the flow when Minecraft loads a mod with a custom mob:

1. Minecraft reads manifest.json to identify the pack and its dependencies.
2. The behavior pack entity file defines what the mob does (components, health, AI, drops).
3. The resource pack entity file links a geometry model and texture to that entity identifier.
4. The spawn rules tell Minecraft where and when to create this mob in the world.
5. The loot table determines what drops when it dies.
6. The animations and animation controllers make it move.
7. Any scripts run to add custom behavior that components can't handle.
8. The language files give it a human-readable name.

Every piece references the others by identifier strings. The behavior pack entity uses "identifier": "blocksmith:shadow_wolf", and the resource pack entity, spawn rules, and loot table all reference that same identifier. Break one link and that piece stops working.

Why This Matters to You

You don't need to memorize all of this to create mods. Tools like BlockSmith generate all these files automatically from a plain English description. But understanding the structure helps you:

• Debug problems. If a mob spawns but is invisible, you know to check the resource pack entity file and texture references.
• Tweak mods. Want to change a mob's health? Open its behavior pack entity JSON and edit the minecraft:health component value.
• Combine mods. Understanding namespaces and UUIDs helps you run multiple mods without conflicts.
• Learn modding. Reading generated files is one of the best ways to learn the format for when you want to build something by hand.

---

Let AI Handle the File Structure

Now that you know what's inside a .mcaddon file, you can appreciate what BlockSmith does: it generates all of these interconnected files — manifests, entities, items, recipes, scripts, textures references, language files — from a single text description. Every UUID is unique, every reference is linked, every format version is correct.