Validating Add-on JSON Before Launching the Game

When you rely entirely on the game's Content Log to find mistakes, you pay a heavy time penalty for trivial typos. If you forget a closing bracket in an entity file, or type an integer where a float or boolean is expected, you have to save the file, switch to Minecraft, run the /reload command—or worse, exit and re-enter the world if you modified something cached on startup like block geometries or item textures—and then read the error log.

There are two distinct layers of JSON checking you can perform before the game ever reads your pack. The first layer is syntax validation: ensuring your brackets match, strings are quoted, and trailing commas are removed. The second layer is schema validation: verifying that your JSON structure actually matches what Minecraft Bedrock expects for a given format_version, such as confirming that a block's components object only contains real block components and not entity components.

A minor catch with external tools is that Minecraft Bedrock itself uses a slightly relaxed JSON parser in many areas—often tolerating C-style comments (// and /* */) and sometimes ignoring trailing commas depending on the subsystem. However, strict external validators will flag these. Treating your add-on files as strict, standard JSON (or explicitly configuring your editor for JSON with Comments, known as JSONC) prevents mysterious parser failures when moving files between different tools.

The fastest way to catch errors is while your fingers are still on the keyboard. Code editors that support the JSON Language Server, most notably Visual Studio Code, can read community-maintained JSON schemas for Bedrock and highlight invalid keys or wrong value types immediately. Extensions built specifically for Bedrock development—such as Blockception's Minecraft Bedrock Development extension—automatically associate files in paths like BP/entities/ or RP/models/ with their matching schemas.

If you are using VS Code, you should configure your workspace settings so that the editor understands both the file associations and the fact that Bedrock allows comments inside JSON files. Without the JSONC association, the editor will paint every comment red, drowning out genuine structural warnings. You can drop a settings file directly into your project's .vscode folder so anyone working on the pack gets the same validation rules.

{
  "files.associations": {
    "*.json": "jsonc",
    "*.material": "jsonc",
    "*.attachable.json": "jsonc"
  },
  "json.validate.enable": true,
  "editor.quickSuggestions": {
    "strings": true
  }
}

A plain syntax checker only cares if your file is legal JSON; a schema validator cares if it is legal Minecraft code. When a schema is active, it inspects the root key—such as minecraft:block, minecraft:entity, or minecraft:item—alongside the format_version string, and checks every nested property against the rules for that specific version.

Consider the valid block definition below. If you accidentally typed "minecraft:destructible_by_mining": 2.5 (passing a raw number instead of an object or boolean), a basic syntax linter would pass the file because a number is valid JSON. A Bedrock-aware schema validator, however, knows that minecraft:destructible_by_mining must be either a boolean or an object containing properties like seconds_to_destroy, and will underline the number immediately.

{
  "format_version": "1.20.80",
  "minecraft:block": {
    "description": {
      "identifier": "wiki:reinforced_slate",
      "menu_category": {
        "category": "construction"
      }
    },
    "components": {
      "minecraft:destructible_by_mining": {
        "seconds_to_destroy": 4.0
      },
      "minecraft:destructible_by_explosion": {
        "explosion_resistance": 12.0
      },
      "minecraft:friction": 0.4,
      "minecraft:map_color": "#3a3d45"
    }
  }
}

Editor highlights only show you errors in the files you currently have open. If you run a global find-and-replace across fifty loot tables or spawn rules, you can easily break a file you never opened in a tab. Before packaging a release or copying files to your com.mojang development folders, running a quick command-line script across your entire BP and RP directories guarantees every single file at least parses cleanly.

If you already have Node.js installed for working with the @minecraft/server Script API, you can write a zero-dependency script that walks your pack folders, strips single-line and multi-line comments, and runs JSON.parse on every .json file. While it does not replace a full schema check, it executes in milliseconds and catches broken syntax from merges or bulk edits before you launch Minecraft.

const fs = require('fs');
const path = require('path');

function stripComments(raw) {
  return raw.replace(/\\"|"(?:\\"|[^"])*"|(\/\/.*|\/\*[\s\S]*?\*\/)/g, (m, g) => g ? "" : m);
}

function scanDir(dir) {
  let errors = 0;
  for (const entry of fs.readdirSync(dir, { withFileTypes: true })) {
    const fullPath = path.join(dir, entry.name);
    if (entry.isDirectory()) {
      errors += scanDir(fullPath);
    } else if (entry.name.endsWith('.json') || entry.name.endsWith('.material')) {
      try {
        const raw = fs.readFileSync(fullPath, 'utf8');
        JSON.parse(stripComments(raw));
      } catch (err) {
        console.error(`[FAIL] ${fullPath}: ${err.message}`);
        errors++;
      }
    }
  }
  return errors;
}

const totalErrors = scanDir('./BP') + scanDir('./RP');
if (totalErrors > 0) {
  console.error(`Found ${totalErrors} invalid JSON file(s).`);
  process.exit(1);
} else {
  console.log('All JSON files parsed cleanly.');
}

Even when every individual JSON file is syntactically pure and passes its schema, your pack can still fail to load if the files disagree with each other. The most important manual or scripted pre-flight check is verifying your BP/manifest.json and RP/manifest.json files. Every UUID in the header and inside the modules array must be unique across both packs; pasting the behaviour pack manifest into the resource pack and forgetting to generate new UUIDs is one of the most frequent reasons a pack fails to appear in the game's pack list.

Beyond manifests, watch out for string references that cross between the behaviour pack and resource pack. Schema tools with workspace indexing will warn you if your block uses a geometry identifier like geometry.wiki.chair that does not exist inside any file in RP/models/blocks/, or if your RP/blocks.json points to a terrain texture shortname that was never defined in RP/textures/terrain_texture.json. Making a habit of checking the Problems panel in your editor for these workspace-wide warnings saves you from debugging purple-and-black missing textures in-game.

{
  "format_version": 2,
  "header": {
    "name": "pack.name",
    "description": "pack.description",
    "uuid": "a1b2c3d4-e5f6-4a5b-8c9d-0e1f2a3b4c5d",
    "version": [1, 0, 0],
    "min_engine_version": [1, 20, 80]
  },
  "modules": [
    {
      "type": "data",
      "uuid": "f6e5d4c3-b2a1-4f5e-9d8c-7b6a5f4e3d2c",
      "version": [1, 0, 0]
    }
  ]
}

Applies to all Minecraft Bedrock versions. No experimental toggles are needed for external JSON validation, though community schemas update frequently to match the latest stable format_version (such as 1.20.80 and 1.21.x).

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