Finding Which File Broke After an Edit

Your first step after any broken edit should be checking the Content Log rather than staring at your code editor. In Minecraft Bedrock, open Settings, navigate to the Creator tab, and enable both Content Log File and Content Log GUI. When you load into a world or run the /reload command, the game parses your modified files and prints any syntax or schema errors directly to the screen and to a log file on your disk.

Pay close attention to the subsystem tags in brackets at the start of each log line, such as [Json], [Blocks], [Entities], or [Molang]. A single typo in one file can cause a cascade of errors across dependent files. For example, if a block definition fails to parse due to a missing comma, the game will also log errors for your terrain_texture.json references or loot tables that expect that block to exist. Always fix the very first error listed in the log after a reload, as later errors are often just side effects of the initial failure.

If the on-screen log disappears too quickly, press the Content Log History shortcut (or open the Creator settings menu while in your world) to review the full session output. On Windows, the raw text file is also written to your local com.mojang folder under the logs directory, which you can search using your code editor.

Sometimes the Content Log shows zero errors, yet your entity, block, or item still does not behave as expected. This is called a silent failure, and it usually happens when your JSON is syntactically valid—meaning all brackets and commas are in the right place—but structurally wrong for the game engine. The parser reads the file without crashing, quietly discards the keys it does not recognize, and loads a half-working asset.

The most common cause of a silent failure after an edit is placing a component in the wrong scope or using a component that requires a newer format_version than the file declares. For instance, if you paste a modern block component like minecraft:destructible_by_mining into an older block file, or accidentally nest a component inside the description object instead of the components object, the engine may simply ignore it. Compare the structure below to your recently edited files to ensure every block sits in its proper parent object.

{
  "format_version": "1.20.80",
  "minecraft:block": {
    "description": {
      "identifier": "wiki:custom_stone",
      "menu_category": {
        "category": "construction"
      }
    },
    "components": {
      "minecraft:destructible_by_mining": {
        "seconds_to_destroy": 2.5
      },
      "minecraft:destructible_by_explosion": {
        "explosion_resistance": 6.0
      },
      "minecraft:geometry": "minecraft:geometry.full_block",
      "minecraft:material_instances": {
        "*": {
          "texture": "custom_stone_tex",
          "render_method": "opaque"
        }
      }
    }
  }
}

When testing edits while a world is already open, developers frequently rely on the /reload command to apply changes quickly. However, /reload only re-evaluates certain behavior pack files, such as functions, loot tables, trade tables, and scripts. It does not reliably reload everything.

If you edit block registries, item components, recipes, entity identifiers, or almost anything inside a resource pack (like models, textures, attachables, or render controllers), running /reload will make you think your edit broke the file because nothing changes in-game. Before assuming your latest edit introduced a bug, save and quit to the main menu, then reload the world from scratch. If you edited manifest.json or added new texture files, it is safest to restart the entire game client so the asset cache refreshes completely.

If you edited a dozen files before testing and the Content Log does not point to a specific filename, let your operating system tell you what changed. Open your development_behavior_packs and development_resource_packs folders in your file manager, use the search bar to list all files (*.*), and sort the results by Date Modified in descending order. The files at the very top of that list are the only ones capable of having caused the new bug.

When a specific file is causing a problem—or when a complex entity or block stops working after a large edit—use the bisection method inside the file itself. Instead of rewriting the file from scratch, cut out half of the components or permutations you recently added, save them to a scratchpad file outside your pack folder, and reload the world. If the asset works again, the bug is in the half you removed. Paste half of that removed code back in and test again. Within three or four reloads, you will narrow the problem down to the exact component or event that is failing.

You can follow the same process at the folder level if your whole pack stops registering. Move half of your recently edited JSON files out of your BP/entities or BP/blocks folder into a temporary folder on your desktop. Because Bedrock loads most definitions independently, removing non-dependent files will quickly reveal which batch contains the bad file.

When your add-on uses the Script API, a single syntax error or bad import in one JavaScript file can halt execution for your entire script module. If your custom scripted mechanics suddenly vanish after an edit, look in the Content Log for the [Scripting] tag. If you use TypeScript, check your compiler terminal first, as a failed build might mean the game is still running an older compiled version of your script or an incomplete output file.

If the script loads without syntax errors, the failure usually happens inside an event callback at runtime. Wrap the code you recently edited in a try/catch block and print the error message and stack trace using console.error(). When Content Log GUI is enabled, console.error() prints in bright red text directly on your screen the exact moment the broken code runs, giving you the file name and line number that threw the exception.

import { world } from "@minecraft/server";

world.afterEvents.itemUse.subscribe((event) => {
  try {
    const player = event.source;
    const item = event.itemStack;

    if (item.typeId === "wiki:debug_wand") {
      player.sendMessage("Wand activated successfully.");
    }
  } catch (err) {
    console.error(`Script failed in itemUse: ${err} | Stack: ${err.stack}`);
  }
});

The most reliable way to find out what broke after an edit is to initialize a local Git repository in your add-on workspace. You do not need to upload your code anywhere; simply running git init in your project folder gives you an instant safety net. Whenever your add-on is in a working state, stage and commit your files.

The next time an edit breaks your pack and you cannot figure out why, run git status or check the Source Control panel in your code editor. It will list every single file modified since the pack last worked. Clicking any file shows a line-by-line diff, immediately exposing accidental keystrokes—like a stray character typed into manifest.json or a deleted bracket in a render controller—that you did not even realize you made. If a file is completely ruined, you can revert that single file back to its working state without losing your progress in other files.

Applies to all modern Minecraft Bedrock versions (1.16.100 through 1.21+). The Content Log settings and /reload command are built into the base game and do not require any experimental toggles.

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