You followed a tutorial, wrote your JSON files, zipped everything up, imported it into Minecraft... and nothing works. Or worse, the game crashes. Sound familiar?
Bedrock modding has a lot of small details that trip up beginners. One wrong character in a JSON file can silently break your entire mod. Here are the 10 most common mistakes and exactly how to fix each one.
1. Using the Wrong Format Version
Every JSON file in a Bedrock add-on starts with a format_version field. This tells Minecraft which version of the data format to expect. Using the wrong version is the single most common cause of mods silently failing.
The problem: You copy code from a tutorial that was written for Minecraft 1.16, but you're playing on 1.21. The format_version says "1.16.0" and uses old syntax that the current game interprets differently — or ignores entirely. Alternatively, you use a format_version that's too new for your game version, and the game can't parse it.
The fix: Always match your format_version to the features you're using. For entities in current Minecraft, use "format_version": "1.21.0" or whatever matches your game version. For manifests, use "format_version": 2. When following old tutorials, update the format_version and check if the syntax has changed in the Bedrock documentation.
2. Duplicate or Missing UUIDs
Every behavior pack and resource pack needs unique UUIDs (those long strings like "a1b2c3d4-e5f6-7890-abcd-ef1234567890") in their manifest.json. These UUIDs identify the pack to Minecraft.
The problem: You copied a template and forgot to generate new UUIDs. Now your pack has the same UUIDs as the template or another mod. Minecraft shows "Duplicate Pack Detected" and refuses to import it. Or you generated UUIDs for the behavior pack but used the same ones in the resource pack.
The fix: Generate fresh UUIDs for every pack you create. Use an online UUID generator (search "UUID generator") and create unique ones for: the behavior pack header, the behavior pack module, the resource pack header, and the resource pack module. That's a minimum of 4 unique UUIDs per mod. Never copy UUIDs between packs.
3. JSON Syntax Errors
JSON is unforgiving. One missing comma, one extra bracket, one unquoted string, and the entire file is invalid. Minecraft won't tell you where the error is — the pack just silently breaks.
The problem: Common culprits include trailing commas after the last item in a list, missing commas between properties, mismatched curly braces or square brackets, and using single quotes instead of double quotes.
The fix: Use a JSON validator before importing your mod. Paste your JSON into jsonlint.com and it'll tell you exactly which line has the error. Better yet, use a code editor like VS Code that highlights JSON errors in real-time with a red underline. VS Code with the Blockception Bedrock Development extension is the best setup for Bedrock modding.
4. Identifier Mismatches
Bedrock add-ons link files together through identifier strings. The behavior pack entity uses "identifier": "mymod:fire_wolf", and the resource pack entity, spawn rules, and loot table must all reference that exact same string.
The problem: The behavior pack says "mymod:fire_wolf" but the resource pack says "mymod:firewolf" (missing underscore). The entity exists in-game but is invisible because the resource pack can't find a matching definition. Or the loot table references "mymod:fire_wolf_loot" but the actual file is named "fire_wolf.json".
The fix: Establish a naming convention and stick to it religiously. Use lowercase with underscores for everything: mymod:fire_wolf, not myMod:FireWolf or MYMOD:FIRE_WOLF. When creating a new entity, search your project for the identifier to make sure every reference matches exactly.
5. Not Using a Namespace
A namespace is the prefix before the colon in identifiers: mymod:fire_wolf. The mymod: part is the namespace.
The problem: You name your custom sword just "super_sword" without a namespace. Another mod also has a "super_sword". When both mods are active, they conflict and one overrides the other. Or worse, your identifier accidentally matches a vanilla Minecraft identifier and you override a base game item.
The fix: Always use a unique namespace for your mod. Something distinctive like blocksmith: or myname_modname:. Apply it to every entity, item, block, and recipe identifier. This prevents conflicts with vanilla content and other mods.
6. Forgetting the Resource Pack
Many beginners focus on the behavior pack (because that's where the "cool stuff" happens) and forget or skip the resource pack.
The problem: You create a custom entity in the behavior pack with health, damage, AI, and spawn rules. You import the mod and the entity spawns... as an invisible hitbox. Or a black-and-purple cube. There's no texture, no model, no animation because you never made the resource pack files.
The fix: Every custom entity, item, and block needs matching resource pack files. At minimum: a client entity definition (linking model + texture + animations), a texture file (.png), and a geometry file (model). Items need a texture and an entry in item_texture.json. Even if you're using placeholder textures, the resource pack structure must exist.
7. Oversized Pack Files
Minecraft has limits on how large add-on files can be, especially on mobile devices and consoles.
The problem: You included high-resolution textures (512x512 or larger) for every entity, uncompressed sound files, or hundreds of unused template files you forgot to delete. The .mcaddon file is 50MB and mobile devices choke on it. Import fails silently or the game lags when loading the pack.
The fix: Keep textures at 16x16 or 32x32 for items and blocks. Entity textures can go up to 64x64 or 128x128 but rarely need more. Compress sound files to .ogg format at reasonable bitrates. Delete any files that aren't actively used by the mod. A well-built mod with 5 entities and 10 items should be under 1MB.
8. Breaking Vanilla Dependencies
Bedrock add-ons can modify vanilla content, not just add new content. This is powerful but dangerous.
The problem: You modified the zombie entity to make it stronger, but your modification accidentally removed a component that other game systems depend on. Now zombies don't burn in sunlight, don't convert villagers, or don't spawn naturally. Or you changed the crafting recipe for a vanilla item and broke an in-game advancement.
The fix: When modifying vanilla entities, copy the entire vanilla JSON file first, then make minimal changes. Never delete components you don't understand. Better yet, avoid modifying vanilla content altogether — create custom entities instead. Instead of making zombies stronger, create a "Super Zombie" custom entity based on the zombie but with your changes.
9. Ignoring Dependency Links
If your behavior pack requires a resource pack (which it almost always does), they need to be linked through dependencies in their manifest files.
The problem: The behavior pack and resource pack work fine when manually activated together, but the resource pack doesn't auto-activate when you enable the behavior pack. Players install the mod and only enable one of the two packs, getting broken results.
The fix: In the behavior pack's manifest.json, add a dependencies section with the resource pack's UUID. In the resource pack's manifest.json, add a dependency on the behavior pack's UUID. When the packs are properly linked, Minecraft auto-activates both when a player enables either one. The .mcaddon container format also helps — it packages both packs together so they import as a unit.
10. Not Testing on the Target Platform
Bedrock runs on six platforms. They don't all behave identically.
The problem: You developed and tested on Windows. The mod works perfectly. You share it with a friend on iOS and nothing works. Or it works on phones but crashes on Xbox. Script API features available on Windows might not be fully supported on older consoles. File path handling differs between platforms. Performance characteristics vary wildly between a gaming PC and a phone.
The fix: Test on at least two platforms if possible. If you only have one device, focus on the most restrictive one (usually mobile). Keep scripts simple and avoid cutting-edge API features that might not be available everywhere. Keep texture sizes small. Monitor frame rate when your mod is active — if it stutters on your device, it'll be unplayable on weaker hardware.
Bonus: The Meta-Mistake
The biggest mistake beginners make isn't any single technical error — it's trying to build too much in their first mod. A mod with 20 custom entities, 50 items, a scripted quest system, and custom textures for everything is overwhelming to debug when (not if) something goes wrong.
Start with one entity. Get it working perfectly: spawning, moving, attacking, dropping loot, looking right. Then add one item. Then one recipe. Build incrementally and test after every addition. When something breaks, you know exactly which change caused it.
Skip the Mistakes Entirely
BlockSmith generates mods that avoid every mistake on this list. Correct format versions, unique UUIDs, valid JSON, matching identifiers, proper namespacing, linked dependencies — all handled automatically. You focus on the fun part: deciding what the mod does.