Reading the Content Log: The First Thing to Turn On

You do not need any external tools or experimental world toggles to turn on the Content Log. It is a global profile setting built directly into the base game client. To enable it, open Minecraft and navigate to Settings from the main menu or the pause screen, then scroll down the left sidebar and select the Creator tab.

Inside the Creator menu, you will see two primary switches: Enable Content Log File and Enable Content Log GUI. You should turn both of these on immediately. Below those toggles, there is a button labeled Content Log History (or openable in-game via your chat and pause menus, depending on your platform). While you are in this menu, make sure the log severity filter is set to show everything, including Verbose, Inform, Warning, and Error messages.

The GUI option prints errors directly onto the top corner of your screen for a few seconds the moment they happen—such as when a world loads or an entity spawns. The File option writes every single message to a persistent text document on your hard drive, which is essential when a pack produces dozens of errors at once and they scroll off the screen too fast to read.

When you have Enable Content Log File switched on, Minecraft creates a fresh text file every time you launch the application. Reading the raw file in a code editor is much easier than squinting at the in-game UI, because you can use your editor's search function to filter by your custom namespace or file name.

On Windows, the logs are stored inside the standard UWP local application data folder, right next to your development packs. Open the Windows Run dialog (Win + R) and navigate to the following directory path to find your logs folder:

%localappdata%\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe\LocalState\logs

A raw Content Log line looks intimidating at first because it packs several pieces of context into a single string. However, every line follows a predictable structure: a timestamp, the engine subsystem that threw the error, the severity level, the pack name or stack trace, and finally the human-readable failure reason.

Understanding the subsystem tags tells you immediately whether you need to open your Behavior Pack or your Resource Pack to fix the problem. The table below breaks down the most common tags and severity levels you will see when debugging an add-on.

The most common bug in add-on development is a simple typo in a JSON file. When a JSON file fails to parse, Minecraft pretends the file does not exist at all. If you try to `/give` yourself a custom block and the game says the block is unknown, your first instinct should be to check the Content Log for a `[Json]` error.

Consider the following custom block definition. It looks almost right at a glance, but it contains two classic mistakes that the Content Log will immediately flag when you load into a world.

{
  "format_version": "1.20.80",
  "minecraft:block": {
    "description": {
      "identifier": "wiki:slate_tile"
    },
    "components": {
      "minecraft:destructible_by_mining": {
        "seconds_to_destroy": "2.5"
      },
      "minecraft:Friction": 0.4
    }
  }
}

If you load a world with the file above, the Content Log will output two distinct messages referencing `BP/blocks/slate_tile.json`. First, it will complain about `seconds_to_destroy` inside `minecraft:destructible_by_mining`. Because `"2.5"` is wrapped in quotation marks, the JSON parser reads it as a string instead of a floating-point number. The log message will state that the property expected a float or number type. Removing the quotes around `2.5` fixes the first error.

Second, the log will flag `minecraft:Friction` as an unknown or unrecognized component. Bedrock identifiers and component keys are strictly case-sensitive and always lowercase. Because the `F` was capitalized, the engine ignores the component entirely and falls back to default block friction. Changing the key to `minecraft:friction` resolves the warning.

Had the file contained a broken comma—such as a trailing comma after `0.4`—the log would instead give you a `[Json][Error]` with a specific line and column number, such as `Line 11, Column 5: Syntax error: value, object or array expected`. Whenever you see a line and column number, jump straight to that line in your text editor; the mistake is almost always on that exact line or the line immediately above it.

Once you start working on a larger add-on, old errors from previous test runs can clutter the in-game Content Log History screen. Get into the habit of pressing the Clear button inside the Content Log History menu right before you trigger the mechanic you are testing, or before you run the `/reload` command.

Speaking of `/reload`, bear in mind that running `/reload` in chat only reloads functions and scripts; it does not re-parse block, item, or entity JSON files. To see if your JSON fixes worked and cleared the Content Log errors, you must save and quit to the main menu, then load back into the world.

Finally, try to keep your add-on at zero warnings, not just zero errors. When a pack generates fifty harmless warnings on world load, it becomes very easy to miss the one new error that explains why your latest entity stopped spawning.

Applies to all modern Bedrock Edition versions (1.16.100 through 1.21+). The Creator settings menu and Content Log are available in stable releases and do not require any experimental toggles.

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