Command Differences That Catch Java Players Out

The single biggest shock for a Java command creator moving to Bedrock is the complete absence of raw NBT manipulation in commands. In Java Edition, commands like `/data get`, `/data merge`, and inline `{Tags:["my_tag"],CustomName:'"Bob"'}` payloads are the backbone of almost every data pack. In Bedrock Edition, you cannot read or write raw entity, block, or item NBT strings through commands.

Instead of modifying an existing entity's NBT on the fly, Bedrock expects you to define behaviors inside an entity's behavior pack JSON file using component groups and events. To change what an entity does, is named, or looks like from a command, you fire an entity event using `/event entity @e[type=...] my_pack:some_event` or summon the entity with a birth event directly in `/summon`.

Commands do still allow a curated, strict subset of item JSON components at the end of `/give`, `/replaceitem`, and `/clear`. These are limited to four specific properties: `minecraft:can_place_on`, `minecraft:can_destroy`, `minecraft:item_lock`, and `minecraft:keep_on_death`. You cannot use `/give` to grant a sword with custom lore, a custom display name, or custom enchantments via JSON strings; for those tasks, you must either use the Script API (`@minecraft/server`) or load a saved structure containing the modified item using `/structure load`.

This architectural split means that pure command creations in Bedrock are much more tightly coupled to behavior pack JSON files and TypeScript than Java data packs are. When you find yourself asking how to test for a specific NBT tag on a player or mob, the Bedrock answer is almost always to use entity properties, scoreboard objectives, `/tag`, or the `hasitem` selector argument.

{
  "format_version": "1.20.40",
  "minecraft:entity": {
    "description": {
      "identifier": "wiki:custom_guard",
      "is_spawnable": true,
      "is_summonable": true
    },
    "component_groups": {
      "wiki:hostile_mode": {
        "minecraft:behavior.nearest_attackable_target": {
          "priority": 2,
          "must_see": true,
          "entity_types": [
            {
              "filters": {
                "test": "is_family",
                "subject": "other",
                "value": "player"
              },
              "max_dist": 16
            }
          ]
        }
      }
    },
    "components": {
      "minecraft:type_family": {
        "family": ["guard", "mob"]
      },
      "minecraft:health": {
        "value": 20,
        "max": 20
      }
    },
    "events": {
      "wiki:become_hostile": {
        "add": {
          "component_groups": ["wiki:hostile_mode"]
        }
      }
    }
  }
}

Bedrock target selectors (`@p`, `@a`, `@r`, `@e`, `@s`) look very familiar at first glance, and there is even a dedicated `@initiator` selector used specifically in NPC dialogue commands to target the player who clicked the NPC. However, the arguments inside the square brackets differ sharply from Java Edition. Using a Java selector argument in a Bedrock `.mcfunction` file will cause the entire function file to fail parsing on world load.

The most common trap is distance and sorting. Java uses `distance=..5` (a range operator) and `sort=nearest,limit=1`. Bedrock retains the older, separated min/max arguments and uses `c` (count) instead of `limit` or `sort`. To select the closest 3 zombies within 5 to 10 blocks in Bedrock, you write `@e[type=zombie,r=10,rm=5,c=3]`. If you pass a negative number to `c`, such as `c=-1`, it reverses the sort order and targets the furthest matching entity instead of the nearest.

Because there is no `nbt={Inventory:[...]}` selector in Bedrock, checking player or entity inventories is handled through the `hasitem` selector argument. This is a remarkably powerful Bedrock-exclusive feature that accepts either a single condition block or an array of conditions. You can check for specific item identifiers, item data values, quantities (which DO support the `..` range syntax, unlike `r`), and specific equipment or container slots.

Scoreboard filtering is nearly identical to Java, using `scores={my_obj=1..5}`. Note that `..` ranges work inside `scores` and `hasitem`, as well as the `has_property` selector filter, even though they do not work for radius (`r`/`rm`), levels (`l`/`lm`), or rotation (`rx`/`rxm`, `ry`/`rym`). Additionally, Bedrock allows the `!` negation operator on several arguments where Java requires different workarounds, such as `type=!player,type=!item`.

Wait-list tutorials from before 2022 will warn you that Bedrock uses the old pre-1.13 `/execute @e ~ ~ ~` syntax. That is no longer true. As of format version 1.19.50 and newer, Bedrock uses the chained `/execute as ... at ... run ...` syntax brought over from Java Edition. If you are writing new `.mcfunction` files today, your `min_engine_version` in `manifest.json` should be at least `[1, 19, 50]` (ideally current stable) so that your functions parse with the modern `/execute` syntax.

While `as`, `at`, `in`, `positioned`, `rotated`, `facing`, `align`, `anchored`, `if`, and `unless` all work the way a Java developer expects, there is one massive omission: **`execute store` does not exist in Bedrock**. In Java, `execute store result score` is how you capture the return value of a command (like how many players matched a selector, how many items `/clear` removed, or a player's current health) into a scoreboard objective.

Because `execute store` is missing, you cannot easily pipe the output of `/testfor` or `/clear` into a scoreboard using pure commands. To count matching entities in pure commands, you instead run `/execute as @e[type=zombie] run scoreboard players add #count my_obj 1` after resetting `#count` to zero. For reading entity health, coordinates, or inventory counts into a scoreboard, Bedrock add-on creators rely on Molang queries inside behavior pack animations/controllers or a few lines of JavaScript using `@minecraft/server`.

One other minor difference in `/execute`: in Bedrock, the slash `/` before the subcommand following `run` is optional in chat, though standard practice in `.mcfunction` files is to omit leading slashes entirely on every line, including after `run`.

{
  "format_version": 2,
  "header": {
    "name": "Modern Execute Pack",
    "description": "Requires min_engine_version 1.19.50+ for new execute syntax in functions",
    "uuid": "a1b2c3d4-e5f6-4a5b-8c9d-0e1f2a3b4c5d",
    "version": [1, 0, 0],
    "min_engine_version": [1, 20, 80]
  },
  "modules": [
    {
      "type": "data",
      "uuid": "b2c3d4e5-f6a7-4b5c-9d0e-1f2a3b4c5d6e",
      "version": [1, 0, 0]
    }
  ]
}

Since Bedrock 1.19.70 and the ongoing flattening of block IDs, numeric data values (like `/setblock ~ ~ ~ stone 1`) have been replaced by explicit block states. While both Java and Bedrock now use square brackets `[]` right after the block identifier in `/setblock`, `/fill`, `/testforblock`, and `execute if block`, the formatting inside those brackets is stricter in Bedrock.

In Java Edition, block state keys and values are unquoted strings separated by an equals sign, such as `minecraft:oak_log[axis=y]` or `minecraft:lit_furnace[facing=north,lit=true]`. In Bedrock Edition, block state names are always enclosed in double quotes `""`, and string values are also enclosed in double quotes. Furthermore, until recent updates unified the separator, Bedrock originally used a colon `:` instead of `=`; modern Bedrock now requires the `=` sign just like Java, but keeps the mandatory quotes around string keys and string values.

Boolean values (`true` and `false`) and integer values (`0`, `1`, `2`) inside Bedrock block states are NOT quoted, whereas string values (`"north"`, `"y"`, `"bottom"`) ARE quoted. Getting this wrong is one of the most frequent causes of syntax errors when porting `/fill` or `/setblock` commands. Additionally, many block state names themselves differ between the two editions: Java's `axis=y` on logs is `"pillar_axis"="y"` in Bedrock, and Java's `facing=north` is often `"minecraft:cardinal_direction"="north"` or `"facing_direction"=2` depending on when the block was introduced.

If you leave the square brackets empty (`minecraft:oak_log[]`) or omit them entirely (`minecraft:oak_log`), Bedrock places the block with its default states. When using `execute if block ~ ~ ~ minecraft:chest ["minecraft:cardinal_direction"="north"]`, you only need to specify the states you actually care about testing; unspecified states act as wildcards.

When modifying inventories, Java creators reach for `/item replace` (which replaced `/replaceitem` in Java 1.17). Bedrock still uses `/replaceitem block` and `/replaceitem entity`. One quirk of Bedrock's `/replaceitem` is that slot numbering and slot names are slightly different: armor slots are individually named (`slot.armor.head`, `slot.armor.chest`, `slot.armor.legs`, `slot.armor.feet`), the offhand is `slot.weapon.offhand`, and `/replaceitem` has an optional `oldItemHandling` mode (`destroy` or `keep`) right before the item name that allows you to avoid overwriting existing items in a slot.

For scoreboards, Bedrock only supports the `dummy` criteria in `/scoreboard objectives add`. In Java, you can create objectives that automatically track `minecraft.custom:minecraft.jump`, `health`, `deathCount`, or `minecraft.mined:minecraft.stone`. None of those automatic criteria exist in Bedrock. Every scoreboard objective in Bedrock is a `dummy` objective, and you must update it manually via commands, animation controllers, or Script API events. On the bright side, Bedrock includes `/scoreboard players random <player> <objective> <min> <max>`, a built-in RNG command that Java creators have had to build math libraries to replicate.

Finally, Bedrock includes a suite of presentation and gameplay commands that have no direct command equivalent in earlier Java versions or work much more simply in Bedrock. `/camera` allows smooth cinematic camera splines and third-person presets without spectator-entity riding hacks; `/hud` lets you hide and show specific vanilla HUD elements like the hunger bar, crosshair, or paperdoll per player; `/inputpermission` can lock a player's movement or camera rotation cleanly without teleport loops; and `/playanimation` can fire any resource pack animation on any entity on demand.

In a Java data pack, to make a function run every game tick or on world load, you place a JSON file at `data/minecraft/tags/function/tick.json` or `load.json`. In a Bedrock behavior pack, there is no `load.json` equivalent in pure functions, and ticking functions are registered in a single file located at `BP/functions/tick.json`.

The format of `BP/functions/tick.json` is a simple JSON object containing a `values` array of function paths relative to the `BP/functions/` folder (without the `.mcfunction` extension). Any function listed here will execute 20 times per second at the world spawn coordinates, with the server itself as the execution context (`@s` is null, and `~ ~ ~` is `0 0 0` or the world spawn depending on context, so always specify `at` or `positioned` inside your functions).

{
  "values": [
    "main_loop",
    "systems/check_players"
  ]
}

Applies to Bedrock Edition 1.19.70 through 1.21+ (requires min_engine_version 1.19.50 or higher in manifest.json to use modern /execute syntax and current block state formatting in .mcfunction files). No experimental toggles are required for any commands covered on this page.

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