You've installed Bedrock mods before. You know they come as .mcaddon files and you activate them on your world. But how does it actually work? How does a bunch of files turn into a fire-breathing dragon in your Minecraft world?
This article explains the entire Bedrock add-on system in plain English. No coding background needed. By the end, you'll understand what every piece does and why.
The Big Picture
Here's the simplest possible explanation: Minecraft Bedrock has a built-in system for loading custom content. That system reads text files (specifically JSON files) that describe new things to add to the game. A "mod" (officially called an "add-on") is just a collection of these text files packaged into a single downloadable file.
Think of it like a recipe book. Minecraft is the kitchen. The add-on is a recipe book with instructions for dishes the kitchen doesn't normally make. The kitchen reads the recipes and makes the dishes. You don't need to rebuild the kitchen — you just give it new recipes.
The Two Types of Packs
Every add-on contains one or both of these:
Behavior Pack (What Things Do)
The behavior pack is the instruction manual. It tells Minecraft: "There's a new mob called Shadow Wolf. It has 30 health. It deals 6 damage. It spawns in forests at night. When it dies, it drops shadow fangs."
Behavior packs define:
- Entities — Mobs and creatures. Their health, damage, AI behavior, what they eat, who they attack, how they move.
- Items — Weapons, tools, food, materials. How much damage they deal, their durability, what category they belong to.
- Blocks — Custom blocks. Their hardness, what tool mines them, whether they emit light.
- Recipes — How to craft new items. Which materials, what pattern in the crafting grid, what comes out.
- Loot tables — What drops when a mob dies or a chest generates.
- Spawn rules — Where and when custom mobs appear in the world.
- Scripts — JavaScript code for complex game logic that JSON alone can't express.
Resource Pack (What Things Look Like)
The resource pack is the art department. It tells Minecraft: "The Shadow Wolf looks like this texture, uses this 3D model, and moves with these animations."
Resource packs define:
- Textures — The images wrapped around models (what things look like).
- Models — The 3D shapes of entities and blocks (their physical form).
- Animations — How entities move (walk cycles, attack swings, idle movements).
- Sounds — Custom audio (mob sounds, item use sounds, ambient audio).
- Names — The display names of everything (what you see in-game instead of the technical ID).
Without a resource pack, custom entities exist but are invisible or appear as default pink-and-black error textures.
JSON: The Language of Bedrock Mods
Almost everything in a Bedrock add-on is written in JSON. JSON stands for JavaScript Object Notation, but you don't need to know JavaScript to understand it. JSON is just a way of organizing information using a specific format.
Here's what JSON looks like in plain English: it uses curly braces to group related information, square brackets for lists, and quotes around names and text values. Numbers don't get quotes. Everything is structured as name-value pairs — "the name of a thing" followed by "the value of that thing."
For example, if you were describing a dog in JSON-style thinking, it might look like: name is "Buddy," breed is "Labrador," age is 5, favorite toys are "ball" and "rope," and is a good boy is true. That's the entire concept of JSON — named values organized in a structure.
Bedrock uses this format to describe everything. A mob's health is a named value. Its damage is a named value. Its behavior is a list of named instructions. The entire game's content is described this way — add-ons just add more descriptions to the pile.
The Component System
This is the core concept that makes Bedrock modding work, and it's actually brilliant in its simplicity.
Instead of writing code that says "when the mob sees a player, walk toward them, then swing arm, then deal damage" — you just attach pre-built components to your entity. Minecraft already has hundreds of components built in. You pick the ones you want like building with LEGO.
Want your mob to have health? Attach the health component and set it to 30. Want it to attack players? Attach the nearest attackable target component and tell it to target players. Want it to walk around? Attach the random stroll component. Want it to drop items when killed? Attach a loot component and point it to a loot table.
Here are some of the most commonly used components:
- minecraft:health — How much health the entity has.
- minecraft:attack — How much melee damage it deals.
- minecraft:movement — How fast it moves.
- minecraft:behavior.nearest_attackable_target — What it chooses to attack.
- minecraft:behavior.melee_attack — How it performs melee attacks.
- minecraft:behavior.random_stroll — Makes it wander around.
- minecraft:behavior.follow_owner — Makes it follow a player (for pets).
- minecraft:loot — What it drops when killed.
- minecraft:rideable — Allows players to ride it.
- minecraft:shooter — Makes it shoot projectiles.
- minecraft:explode — Makes it explode (like a creeper).
- minecraft:tameable — Allows players to tame it with items.
Every vanilla mob in the game is built from these same components. A creeper is just an entity with a health component, a movement component, a target component, and an explode component. You can build custom mobs using the exact same building blocks.
Events: Making Things Happen
Components define what an entity IS. Events define what HAPPENS to it in response to triggers.
Events are the "if this, then that" of Bedrock modding. If the entity's health drops below 50%, trigger an event that adds a speed boost component (making it run faster when hurt). If a player feeds it wheat, trigger an event that switches it from "wild" to "tamed" mode.
Events work through component groups. You define groups of components, then events add or remove those groups. For example:
- Component group "phase1": Normal speed, normal damage.
- Component group "phase2": Fast speed, high damage, glowing effect.
- Event "enter_phase2": Remove group "phase1", add group "phase2".
- Trigger: When health drops below 50%, fire event "enter_phase2".
This system lets you create mobs that change behavior dynamically — bosses with phases, animals that flee when hurt, friendly NPCs that turn hostile if attacked. All without writing a single line of code.
The Script API: When JSON Isn't Enough
The component and event system handles most mod needs. But some things are too complex for JSON — custom game logic, player interaction tracking, dynamic scoreboard systems, or procedural generation.
That's where the Script API comes in. It lets you write JavaScript code that runs inside Minecraft. Scripts can listen for game events (a player breaking a block, an entity dying, a chat command being typed), do calculations, and make things happen in response.
Think of scripts as the "glue" that connects things in ways the component system wasn't designed for. You can build entire minigames, economy systems, and quest lines with scripts. Most casual mods don't need them, but they're there when you want to go beyond what components can do.
How Minecraft Loads It All
When you activate an add-on on a world, here's what Minecraft does behind the scenes:
- Reads the manifest to identify the pack, check compatibility, and resolve dependencies.
- Loads behavior pack data — registers new entities, items, blocks, recipes, spawn rules, and loot tables into the game's registry.
- Loads resource pack data — registers textures, models, animations, and sounds so the game knows how to render custom content.
- Starts scripts (if any) — begins running JavaScript files in a sandboxed environment.
- Applies spawn rules — custom mobs start appearing in the world according to their spawn rules.
- Enables recipes — custom crafting recipes become available in the crafting table.
All of this happens automatically. You don't configure anything beyond activating the pack on your world. The system is designed to "just work" as long as the files are correctly structured.
Why This Matters
Understanding how add-ons work gives you three superpowers:
- Better mod descriptions. When you use an AI tool like BlockSmith to generate mods, knowing the system lets you write more precise descriptions. Instead of "a cool dragon," you can say "a rideable entity with a shooter component that fires fireballs, 200 health, flies, and is tameable with blaze rods." The AI generates better output when you speak its language.
- Debugging ability. When a mod doesn't work, you can reason about why. If a mob is invisible, you know it's a resource pack issue. If it doesn't spawn, it's a spawn rule issue. If it doesn't drop loot, it's a loot table issue. You can fix problems without starting from scratch.
- Creative possibilities. Knowing what components exist tells you what's possible. You might not have known mobs can be rideable, tameable, or given shooter abilities until you learned about the component system. Now you can combine those components in ways nobody has tried before.
Build Add-ons Without the Technical Work
BlockSmith handles all the JSON, manifests, components, events, and file structure automatically. You describe what you want in plain English, and the AI generates a complete, correctly structured Bedrock add-on. Understanding the system is optional — but now that you do, you'll get even better results.