This article is about the command in the current version (since Java Edition 1.13 (17w45a) and Bedrock Edition 1.19.50 (beta 1.19.50.23)). For the command in former game versions, see Commands/execute/Before.

Executes another command but allows changing the executor, changing the position and angle it is executed at, adding preconditions, and storing its result.

/execute
Permission level
required
  • 2 ‌[JE only]
  • 1 ‌[BE only]
Restrictions

Cheats only‌[BE only]

Usage Edit

There are fourteen‌[JE only] / eleven‌[BE only] subcommands (aka. instructions) for the /execute command. Multiple subcommands can be chained after /execute. Subcommands are divided into 4‌[JE only] / 3‌[BE only] categories: modifier subcommands, condition subcommands, store subcommands‌[JE only], and the run subcommand.

  • Modifier subcommands modify execution context variables to change the context the command is executed in. Subcommands following it execute with specific executor(s), execution position(s), execution dimension(s), execution rotation(s) and execution anchor.
  • Condition subcommands are used to test whether certain conditions are met, and either output the result or limit the execution of following subcommands.
  • Store subcommands[JE only] can store the output values of the command in a scoreboard or the data of an entity, block entity, or command storage, and can also change the maximum or current value of a bossbar.
  • run subcommand is used for carrying out another command.

All needed subcommands can be concatenated together. Subcommands other than the run subcommand can be arranged arbitrarily and used multiple times. The run subcommand can be used only once, at the end of the chain. Only a run subcommand or a condition subcommand may finalize the chain; otherwise, the command is unparseable.

Subcommands and forking Edit

The game processes the subcommand chain in order — from left to right. For example, the following commands are different:

  • All entities move one block forward: execute as @e at @s run tp ^ ^ ^1
  • All entities are teleported to one block in front of the executor: execute at @s as @e run tp ^ ^ ^1

Some subcommands can fork the command execution into multiple branches, causing subcommands following it to be executed multiple times. For example, when the as subcommand selects multiple entities, the subcommands following it execute once per entity.

If the /execute command doesn't fork, it has only one branch — the main branch.

A branch may terminate halfway if, for example, the condition in a condition subcommand isn't met, or the as subcommand selects zero entities. When terminating, a red message is shown.‌[BE only] If all branches terminate, the /execute command is said to have terminated.

Forking is different between Java Edition and Bedrock Edition (see also MC-125067 — resolved as "Won't Fix". and MCPE-165278 — resolved as "Unresolved".):

  • In Java Edition, the game processes subcommands in breadth-first, that is, executes subcommands one by one. So the game processes other subcommands before processing run subcommands, so the run subcommand cannot affect other subcommands.
  • In Bedrock Edition, the game processes subcommands in depth-first. That is, after forking, all the following subcommands are considered as a whole and are executed once for each branch.
  • For example, when there are two armor stands (A and B) in the world, and a player executes execute as @e[type=armor_stand] as @e[type=armor_stand] run summon armor_stand, the behaviors of Java Edition and Bedrock Edition are shown in the following pictures:

Note that ... run execute ... has no overall effect in both versions. For example, the following commands are identical:

  • execute as @e[type=armor_stand] as @e[type=armor_stand] run summon armor_stand
  • execute as @e[type=armor_stand] run execute as @e[type=armor_stand] run execute run execute run summon armor_stand

In Java Edition, depth-first can be achieved via /function, for example:

  • When there are two armor stands (A and B) in the world, and a player executes execute as @e[type=armor_stand] run function test, and in the function file is:
    • execute as @e[type=armor_stand] run summon armor_stand
  • It behaves like /execute as @e[type=armor_stand] as @e[type=armor_stand] run summon armor_stand in Bedrock Edition.

In Bedrock Edition, there is no way to achieve breadth-first.

Output values Edit

Main article: Commands § Output

Stored values Edit

This feature is exclusive to Java Edition.
 

In Java Edition, a branch outputs a success value and a result value (see also Commands#Output) after it is fully executed (does not terminate halfway). These two output values:

  • Are the outputs of each execution branch, rather than the /execute command itself;
  • Come from the last subcommand (may be a condition subcommand or a run subcommand).
  • Both are integers. The success value is always 0 or 1. The result value is rounded down if not an integer.
  • If in a branch the last subcommand fails, both the two values are 0 in the branch.
  • The two values can be stored through store subcommands‌[Java Edition only].

Note that these two values are from the conditional subcommand at the end or from the command in the run subcommand, and are the output values of each branch, rather than of the whole /execute command.

If executing /function command in the run subcommand, these two output values are not available under certain conditions. See the /function for details.

If the command execution is forked after a store subcommand, the storage operation is applied on each branch. The output value of each branch is stored after the branch is fully executed. If the store locations are the same between all branches, the output value of a later-executing branch directly overwrites the output value of the earlier-executed branch, rather than being accumulated. So, after the whole /execute command is executed, the value at this storage location is the output of the last branch executed.

Success count Edit

Like most commands, /execute command itself also has a success count (whether or not terminates halfway):

  • It is the output value of the /execute command itself, rather than of each execution branch.
  • It comes from the last subcommand (may be a condition subcommand or a run subcommand).
  • The success counts of all branches are summed up.
  • It is an integer greater than or equal to 0.
  • When executing it with a command block, the success count is passed into the command block, which can be checked with a chained conditional command block or be read with a redstone comparator.

Syntax Edit

There are fourteen‌[JE only] / eleven‌[BE only] instructions (aka. subcommands) for the /execute command, and each has its own special syntax, so describing syntax takes a large branching tree.

Full syntax tree
  • Java Edition
/execute ...
  • ... align <axes> -> execute
  • ... anchored <anchor> -> execute
  • ... as <targets> -> execute
  • ... at <targets> -> execute
  • ... facing (<pos>|entity <targets> <anchor>) -> execute
  • ... in <dimension> -> execute
  • ... on <relation> -> execute
  • ... positioned (<pos>|as <targets>|over <heightmap>) -> execute
  • ... rotated (<rot>|as <targets>) -> execute
  • ... store (result|success) ...
    • ... block <targetPos> <path> <type> <scale> -> execute
    • ... bossbar <id> (max|value) -> execute
    • ... entity <target> <path> <type> <scale> -> execute
    • ... score <targets> <objective> -> execute
    • ... storage <target> <path> <type> <scale> -> execute
  • ... summon <entity> -> execute
  • ... (if|unless) ...
    • ... biome <pos> <biome> -> [execute]
    • ... block <pos> <block> -> [execute]
    • ... blocks <start> <end> <destination> (all|masked) -> [execute]
    • ... data ...
      • ... block <sourcePos> <path> -> [execute]
      • ... entity <source> <path> -> [execute]
      • ... storage <source> <path> -> [execute]
    • ... dimension <dimension> -> [execute]
    • ... entity <entities> -> [execute]
    • ... function <function> -> execute
    • ... items ...
      • ... block <sourcePos> <slots> <item_predicate> -> [execute]
      • ... entity <source> <slots> <item_predicate> -> [execute]
    • ... loaded <pos> -> [execute]
    • ... predicate <predicate> -> [execute]
    • ... score <target> <targetObjective> ...
      • ... (<|<=|=|>|>=) <source> <sourceObjective> -> [execute]
      • ... matches <range> -> [execute]
  • ... run <command>
where -> execute represents the start of another subcommand that is required; -> [execute] represents the start of another subcommand that is optional.
  • Bedrock Edition
/execute ...
  • ... align <axes: string> <chainedCommand: ExecuteChainedOption_0>
  • ... anchored <eyes|feet> <chainedCommand: ExecuteChainedOption_0>
  • ... as <origin: target> <chainedCommand: ExecuteChainedOption_0>
  • ... at <origin: target> <chainedCommand: ExecuteChainedOption_0>
  • ... facing ...
    • ... <position: x y z> <chainedCommand: ExecuteChainedOption_0>
    • ... entity <origin: target> <eyes|feet> <chainedCommand: ExecuteChainedOption_0>
  • ... in <dimension: Dimension> <chainedCommand: ExecuteChainedOption_0>
  • ... positioned ...
    • ... <position: x y z> <chainedCommand: ExecuteChainedOption_0>
    • ... as <origin: target> <chainedCommand: ExecuteChainedOption_0>
  • ... rotated ...
    • ... <yaw: value> <pitch: value> <chainedCommand: ExecuteChainedOption_0>
    • ... as <origin: target> <chainedCommand: ExecuteChainedOption_0>
  • ... <subcommand: Option_If_Unless> ...
    • ... block <position: x y z> <block: Block> ...
      • ... <blockStates: block states> [chainedCommand: ExecuteChainedOption_0]
      • ... [chainedCommand: ExecuteChainedOption_0]
    • ... blocks <begin: x y z> <end: x y z> <destination: x y z> <scan mode: BlocksScanMode> [chainedCommand: ExecuteChainedOption_0]
    • ... entity <target: target> [chainedCommand: ExecuteChainedOption_0]
    • ... score <target: target> <objective: string> ...
      • ... <operation: compare operator> <source: target> <objective: string> [chainedCommand: ExecuteChainedOption_0]
      • ... matches <range: integer range> [chainedCommand: ExecuteChainedOption_0]
  • ... run <command: command>
where chainedCommand: ExecuteChainedOption_0 represents the start of another subcommand.

Modifier subcommands Edit

align Edit

Updates the execution position, aligning to its current block position (integer coordinates). Applies only along specified axes.
This is akin to flooring the coordinates – i.e. rounding them downward.
Syntax
Java Edition:
align <axes> -> execute
Bedrock Edition:
align <axes: string> <chainedCommand: ExecuteChainedOption_0>
Arguments
JE<axes>: swizzle
BE: axes: string: basic_string
Any non-repeating combination of the characters 'x', 'y', and 'z'. Axes can be declared in any order, but they cannot duplicate. (For example, x, xz, zyx, or yz.)
Result
Execution position in the given axes are floored, changing by less than 1 block.
Unparseable if the argument is not specified correctly.
Example
Given (-1.8, 2.3, 5.9), execute align xz changes the position to (-2, 2.3, 5).
Given (2.4, -1.1, 3.8), execute align yxz run spawnpoint @p ~ ~ ~ sets the player's spawnpoint to (2, -2, 3).

anchored Edit

Sets the execution anchor to the eyes or feet. Defaults to feet.
Running positioned <pos> -> execute resets to feet.
Effectively recenters local coordinates on either the eyes or feet, also changing the angle of the facing subcommand (of /execute and /teleport) works off of.
See also MCPE-162681 and MCPE-165051 for issues about Bedrock Edition.
Syntax
Java Edition:
anchored <anchor> -> execute
Bedrock Edition:
anchored <eyes|feet> <chainedCommand: ExecuteChainedOption_0>
Arguments
JE<anchor>: entity_anchor
BE: eyes|feet
Whether to anchor the executed command to eyes or feet.
Must be either eyes or feet.
Result
Execution anchor is set to either the eyes or the feet.
Unparseable if the argument is not specified correctly.
Example
The effect of /tp is to move a target by placing its feet at the given position.
execute anchored eyes run tp ^ ^ ^ effectively teleports the executor's feet to where its eyes are.
execute anchored eyes run tp ^5 ^ ^ means "place the executor's feet 5 blocks left of where its eyes are"

as Edit

Sets the executor to target entity, without changing execution position, rotation, dimension, and anchor.
Syntax
Java Edition:
as <targets> -> execute
Bedrock Edition:
as <origin: target> <chainedCommand: ExecuteChainedOption_0>
Arguments
JE<targets>: entity
BE: origin: target: CommandSelector<Actor>
Target entity/entities to become the new executor.
Must be a player name, a target selector or a UUID[Java Edition only].
Result
Executor is updated to target entity (which changes the meaning of @s).
Unparseable if the argument is not specified correctly.
Forks if <targets> or origin: target selects multiple entities.
Terminates current branch if <targets> or origin: target fails to resolve to one or more entities (named players must be online).
Example
Kill all sheep: execute as @e[type=sheep] run kill @s
Make all villagers in loaded chunks invincible: execute as @e[type=villager] run data merge entity @s {Invulnerable:1}[Java Edition only]

at Edit

Sets the execution position, rotation, and dimension to match those of an entity; does not change executor.
Syntax
Java Edition:
at <targets> -> execute
Bedrock Edition:
at <origin: target> <chainedCommand: ExecuteChainedOption_0>
Arguments
JE<targets>: entity
BE: origin: target: CommandSelector<Actor>
Target entity/entities to match position, rotation, and dimension with.
Must be a player name, a target selector or a UUID[Java Edition only].
Result
Execution position, rotation, and dimension are updated to match target entity.
Unparseable if the argument is not specified correctly.
Forks if <targets> or origin: target selects multiple entities.
Terminates current branch if <targets> or origin: target fails to resolve to one or more entities (named players must be online).
Example
Move all sheep upward 1 block: execute as @e[type=sheep] at @s run tp ~ ~1 ~
Kill the player running the command, because "at" does not change the executor: execute at @e[type=sheep] run kill @s

facing Edit

Sets the execution rotation to face a given point, as viewed from its anchor (either the eyes or the feet).
Syntax
Java Edition:
facing <pos> -> execute
facing entity <targets> <anchor> -> execute
Bedrock Edition:
facing <position: x y z> <chainedCommand: ExecuteChainedOption_0>
facing entity <origin: target> <eyes|feet> <chainedCommand: ExecuteChainedOption_0>
Arguments
Options: facing <pos> and facing <position: x y z>
JE<pos>: vec3
BE: position: x y z: CommandPositionFloat
Coordinates to rotate toward.
Must be three-dimensional coordinates with double-precision floating-point number[Java Edition only] or single-precision floating-point number[Bedrock Edition only] elements. Accepts tilde and caret notations.
Options: facing entity <targets> <anchor> and facing entity <origin: target> <eyes|feet>
JE<targets>: entity
BE: origin: target: CommandSelector<Actor>
The target(s) to rotate toward.
Must be a player name, a target selector or a UUID[Java Edition only].
JE<anchor>: entity_anchor
BE: eyes|feet: enum
Whether to face the target's eyes or feet
Must be either eyes or feet.
Result
Execution rotation is updated to face given position or targets.
Unparseable if the argument is not specified correctly.
Forks if <targets> or origin: target selects multiple entities.
Terminates current branch if <targets> or origin: target fails to resolve to one or more entities (named players must be online).
Example
Executor rotates once to the left: execute facing ^1 ^ ^ run tp @s ~ ~ ~ ~ ~
All entities move one block in the direction of (0, 64, 0) (without changing their rotation): execute as @e at @s facing 0 64 0 run tp @s ^ ^ ^1
All entities move one block in the direction of (0, 64, 0) (with changing their rotation): execute as @e at @s facing 0 64 0 run tp ^ ^ ^1 ~ ~
All non player entities move one space in the direction of their nearest player (without changing their rotation): execute as @e[type=!player] at @s facing entity @p feet run tp @s ^ ^ ^1

in Edit

Sets the execution dimension and execution position.
It respects dimension scaling for relative and local coordinates: the execution position (only the X/Z part) is divided by 8 when changing from the Overworld to the Nether, and is multiplied by 8 when vice versa. Applies to custom dimensions as well.
Syntax
Java Edition:
in <dimension> -> execute
Bedrock Edition:
in <dimension: Dimension> <chainedCommand: ExecuteChainedOption_0>
Arguments
JE<dimension>: dimension
BE: dimension: Dimension: enum
ID of the new execution dimension.
In Java Edition, must be a resource location, which resolves into a dimension during command execution. In Bedrock Edition, must be either overworld, nether, or the_end.
Result
Execution dimension and position is updated.
Unparseable if the argument is not specified correctly.
Example
Looking for an end city (from the overworld):
  • execute in minecraft:the_end run locate structure minecraft:end_city[Java Edition only]
  • execute in the_end run locate structure end_city[Bedrock Edition only]
If a player at position (16,64,16) in Overworld runs the following command, the player is teleported to (16,64,16) in the Nether:
  • execute in minecraft:the_nether positioned as @s run tp ~ ~ ~[Java Edition only]
  • execute in nether positioned as @s run tp ~ ~ ~[Bedrock Edition only]
If a player at position (16,64,16) in Overworld runs the following command, the player is teleported to (2,64,2) in the Nether.
If a player at position (80,64,80) in Overworld runs the following command, the player is teleported to (10,64,15) in the Nether.

on Edit

This feature is exclusive to Java Edition.
 
Updates the executor to entities selected based on relation to the current executor entity. without changing execution position, rotation, dimension, and anchor.
Syntax
Java Edition:
on <relation> -> execute
Arguments
JE: <relation>
A relation to the current executor entity.
  • attacker: the last entity that damaged the current executor entity in the previous 5 seconds. Note that damage types in minecraft:no_anger tag bypass the record of attacker. Interaction entities do not forget attacker after 5 seconds. Some mobs forget the attacker when ceasing their aggression.
  • controller: the entity that is riding and controlling the current executor entity. See Riding#Controlling for details.
  • leasher: the entity leading the current executor entity with a leash.
  • origin: the entity that cause the summon of the current executor entity. For example, the shooter of an arrow, the primer of a primed TNT entity.
  • owner: the owner of the current executor entity if it is a tameable animal.
  • passengers: all entities that are directly riding the current executor entity, no sub-passengers.
  • target: the target that the current executor entity intends on attacking. Interaction entities can select the last entity that interacted with them.
  • vehicle: the entity ridden by the current executor entity.
Result
Executor is updated based on the relation with the executor entity (which changes the meaning of @s).
Forks if passengers selects multiple entities. (Other relations can select only at most one entities.)
Terminates current branch if the current executor is not an entity.
Terminates current branch if the relation is not applicable to the current executor entity or there are no entities matching it.
Example
Damage 1 heart the entity that is leashing a cat: execute as @e[type=cat] on leasher run damage @s 2 generic
Give all players riding a boat a fishing rod: execute as @e[type=boat] on passengers run give @s fishing_rod

positioned Edit

Sets the execution position, without changing execution rotation or dimension; can match an entity's position, or at one block above the Y-level stored in the specified heightmap[JE only].
Syntax
Java Edition:
positioned <pos> -> execute
positioned as <targets> -> execute
positioned over <heightmap> -> execute
Bedrock Edition:
positioned <position: x y z> <chainedCommand: ExecuteChainedOption_0>
positioned as <origin: target> <chainedCommand: ExecuteChainedOption_0>
Arguments
Option: positioned <pos> or positioned <position: x y z>
JE<pos>: vec3
BE: position: x y z: CommandPositionFloat
New position.
Must be three-dimensional coordinates with double-precision floating-point number[Java Edition only] or single-precision floating-point number[Bedrock Edition only] elements. Accepts tilde and caret notations.
Option: positioned as <targets> or positioned as <origin: target>
JE<targets>: entity
BE: origin: target: CommandSelector<Actor>
Target entity/entities to match position with.
Must be a player name, a target selector or a UUID[Java Edition only].
Option: positioned over <heightmap>
JE: <heightmap>: heightmap
Specifies the heightmap.
Must be one of world_surface, motion_blocking, motion_blocking_no_leaves, and ocean_floor.
Result
Execution position is updated. And positioned <pos> also resets execution anchor to feet.
Unparseable if the argument is not specified correctly.
Forks if <targets> or origin: target selects multiple entities.
Terminates current branch if <targets> or origin: target fails to resolve to one or more entities (named players must be online).
Example
Look for a village near (0, 64, 0):
  • execute positioned 0 64 0 run locate structure #village[Java Edition only]
  • execute positioned 0 64 0 run locate structure village[Bedrock Edition only]

rotated Edit

Sets the execution rotation; can match an entity's rotation.
Syntax
Java Edition:
rotated <rot> -> execute
rotated as <targets> -> execute
Bedrock Edition:
rotated <yaw: value> <pitch: value> <chainedCommand: ExecuteChainedOption_0>
rotated as <origin: target> <chainedCommand: ExecuteChainedOption_0>
Arguments
Option: rotated <rot> or rotated <yaw: value> <pitch: value>
JE: <rot>: rotation (<yaw> <pitch>)
BE: yaw: value: RelativeFloat and pitch: value: RelativeFloat
Angles of rotation.
Must be a rotation consisting of two double‌[JE only] or float‌[BE only] number elements, including yaw and pitch, measured in degrees.
  • For the horizontal rotation (yaw), -180.0 for due north, -90.0 for due east, 0.0 for due south, 90.0 for due west, to 179.9 for just west of due north, before wrapping back around to -180.0.
  • For the vertical rotation (pitch), -90.0 for straight up to 90.0 for straight down.
Tilde notation can be used to specify a rotation relative to the execution rotation.
Option: rotated as <targets> or rotated as <origin: target>
JE<targets>: entity
BE: origin: target: CommandSelector<Actor>
Target entity/entities to match rotation with.
Must be a player name, a target selector or a UUID[Java Edition only].
Result
Execution rotation is updated.
Unparseable if the argument is not specified correctly.
Forks if <targets> or origin: target selects multiple entities.
Terminates current branch if <targets> or origin: target fails to resolve to one or more valid entities (named players must be online).
Example
Move every sheep 1 block in the direction that the player closest to it is facing: execute as @e[type=sheep] at @sORpositioned as @s rotated as @p run tp @s ^ ^ ^1

summon Edit

This feature is exclusive to Java Edition.
 
Summons a new entity at execution position and changes the executor to this summoned entity.
Syntax
Java Edition:
summon <entity> -> execute
Arguments
JE: <entity>: resource
The entity to be summoned and become the new executor.
Must be an existing registered resource location in minecraft:entity_type registry.
Result
Summons the entity and changes the executor.
Unparseable if the argument is not specified correctly.
Terminates current branch if execution position's <x> or <z> exceeds the range of [-30000000, 30000000), or <y> exceeds the range of [-20000000, 20000000).
Terminates the whole /execute command if the specified entity is minecraft:player or minecraft:fishing_bobber.
Example
Summon a sheep with the tag "Test": execute summon sheep run tag @s add Test
Summon a block display entiy and scale it: execute summon block_display run data merge entity @s {transformation:{scale:[4.0,4.0,4.0]},block_state:{Name:"minecraft:dirt"}}

Condition subcommands Edit

The particular use of the if and unless subcommands are to restrict command execution to happen only under specified conditions. In most cases, unless is a negation of if, equivalent to "if not...". The two subcommands have identical argument structures.

Result of condition subcommands
Unparseable if the arguments are not specified correctly.
In some cases, for example, testing a block outside the world, both if and unless terminates or fails.
When not at the end of the subcommands chain, only if the condition tests pass does the branch continue; otherwise it terminates.
In Java Edition, if it is executed in multiple branches, it acts as a context filter (only branches with contexts that match the condition continue).
When at the end of the subcommands chain, it checks whether the condition is met and then outputs. In Java Edition, it has output values that can be stored by store subcommands.

There are eleven‌[JE only]) / four‌[BE only] different types of conditions:

  1. (if|unless) biome – Tests the biome in a position‌[Java Edition only]
  2. (if|unless) block – Tests a single block
  3. (if|unless) blocks – Tests blocks in a 3D rectangular volume against another
  4. (if|unless) data – Tests for the data held by a block entity, an entity, or a storage‌[Java Edition only]
  5. (if|unless) dimension - Tests the dimension of the execution‌[Java Edition only]
  6. (if|unless) entity – Tests whether an entity like the one given is real
  7. (if|unless) function – Runs a function or function tag and tests its return value‌[Java Edition only]
  8. (if|unless) items – Tests an inventory slot for a given item‌[Java Edition only]
  9. (if|unless) loaded – Tests if a given position is loaded in the world‌[Java Edition only]
  10. (if|unless) predicate – Tests a predicate[Java Edition only]
  11. (if|unless) score - Tests a target's score

(if|unless) biome Edit

This feature is exclusive to Java Edition.
 
Checks for a specific biome in a given position.
Syntax
(if|unless) biome <pos> <biome> -> [execute]
Arguments
<pos>: block_pos
Position to test.
Must be a block position composed of <X>, <Y> and <Z>, each of which must be an integer or a tilde and caret notation.
<biome>: resource_or_tag
Biome(s) to test for.
Must be an existing registered resource location or tag in minecraft:worldgen/biome registry.
Result
Unparseable if the argument is not specified correctly.
In following conditions, terminates current branch when this subcommand is not at the end of the subcommand chain; fails when at the end:
  • If <pos> is unloaded or out of the world.
  • If test doesn't pass.
When at the end of the subcommand chain, if the command is successful, both success value and result value are 1.

(if|unless) block Edit

Compares the block at a given position to a given block ID or a block tag‌[Java Edition only]
Syntax
Java Edition:
(if|unless) block <pos> <block> -> [execute]
Bedrock Edition:
<subcommand: Option_If_Unless> block <position: x y z> <block: Block> [chainedCommand: ExecuteChainedOption_0]
<subcommand: Option_If_Unless> block <position: x y z> <block: Block> <blockStates: block states> [chainedCommand: ExecuteChainedOption_0]
Arguments
JE<pos>: block_pos
BE: position: x y z: CommandPosition
Position of a target block to test.
In Java Edition, must be a block position composed of <X>, <Y> and <Z>, each of which must be an integer or a tilde and caret notation. In Bedrock Edition, must be a three-dimensional coordinates composed of <X>, <Y> and <Z>, each of which must be a single-precision floating-point number or tilde and caret notation.
JE<block>: block_predicate
BE: block: Block: enum
Specifies the block to test for.
In Java Edition, must be in the format of block_id[block_states]{data_tags}(accepts block tags), in which block states and data tags can be omitted when they are not needed. In Bedrock Edition, must be a block id.
BE: blockStates: block states: BlockStateCommandParam
Specifies the block state for the specified block to test for.
Must be a blockstate argument as ["<state1>"=<value1>,"<state2>"=<value2>,...]. For example: ["old_leaf_type"="birch","persistent_bit"=true].
Result
Unparseable if the argument is not specified correctly.
In following conditions, terminates current branch when this subcommand is not at the end of the subcommand chain; fails when at the end:
  • If <pos> or position: x y z is unloaded or out of the world.
  • If test doesn't pass.
In Java Edition, when at the end of the subcommand chain, if the command is successful, both success value and result value are 1.

(if|unless) blocks Edit

Compares the blocks in two equally sized volumes.
Syntax
Java Edition:
(if|unless) blocks <start> <end> <destination> (all|masked) -> [execute]
Bedrock Edition:
<subcommand: Option_If_Unless> blocks <begin: x y z> <end: x y z> <destination: x y z> <scan mode: BlocksScanMode> [chainedCommand: ExecuteChainedOption_0]
Arguments
JE<start>: block_pos
BE: begin: x y z: CommandPosition
JE<end>: block_pos
BE: end: x y z: CommandPosition
Positions of any two diagonal corners of the source volume (the volume to compare).
In Java Edition, must be a block position composed of <X>, <Y> and <Z>, each of which must be an integer or a tilde and caret notation. In Bedrock Edition, must be a three-dimensional coordinates composed of <X>, <Y> and <Z>, each of which must be a single-precision floating-point number or tilde and caret notation.
JE<destination>: block_pos
BE: destination: x y z: CommandPosition
Position of the lower northwest corner of the destination volume (the volume to compare to).
Assumed to be of the same size as the source volume
In Java Edition, must be a block position composed of <X>, <Y> and <Z>, each of which must be an integer or a tilde and caret notation. In Bedrock Edition, must be a three-dimensional coordinates composed of <X>, <Y> and <Z>, each of which must be a single-precision floating-point number or tilde and caret notation.
JE: (all|masked)
BE: scan mode: BlocksScanMode: enum
Specifies whether all blocks in the source volume should be compared, or if air blocks should be masked/ignored.
Must be either all or masked.
Result
Unparseable if the argument is not specified correctly.
In following conditions, terminates current branch when this subcommand is not at end of the subcommand chain; fails when at the end:
  • If <start> / begin: x y z, <end> / end: x y z, or <destination> / destination: x y z is unloaded or out of the world.
  • If the volume of the source region is greater than 32768 (the equivalent of 8 chunk sections).
  • If test doesn't pass.
In Java Edition, when at the end of the subcommand chain, if the command is successful:
The success value is 1.
For if mode, result value is the number of matching blocks (the total number of blocks in all mode, or the number of source region non-air blocks in masked mode).
For unless mode, result value is 1.

(if|unless) data Edit

This feature is exclusive to Java Edition.
 
Checks whether the targeted block, entity or storage has any data tag for a given path.
Syntax
(if|unless) data block <pos> <path> -> [execute] – for data checking a block
(if|unless) data entity <target> <path> -> [execute] – for data checking an entity
(if|unless) data storage <source> <path> -> [execute] – for data checking a storage
Arguments
Option: (if|unless) data block <pos> <path>
<pos>: block_pos
Position of the block for data testing.
Must be a block position composed of <X>, <Y> and <Z>, each of which must be an integer or a tilde and caret notation.
<path>: nbt_path
Data path to check whether the block has.
Must be an NBT path.
Option: (if|unless) data entity <target> <path>
<target>: entity
A single entity for data testing.
Must be a player name, a target selector or a UUID. And the target selector must be in single type.
<path>: nbt_path
Data path to check whether the entity has.
Must be an NBT path.
Option: (if|unless) data storage <source> <path>
<source>: resource_location
The resource location of the storage for data testing.
Must be a resource location for an unregistered content.
<path>: nbt_path
Data path to check whether the storage has.
Must be an NBT path.
Result
Unparseable if the argument is not specified correctly.
In following conditions, terminates current branch when this subcommand is not at the end of the subcommand chain; fails when at the end:
  • If <pos> is unloaded or out of the world.
  • If block at <pos> isn't a block entity.
  • If <target> fails to resolve to one or more valid entities (named players must be online).
  • If test doesn't pass.
When at the end of the subcommand chain, if the command is successful:
The success value is 1.
For if mode, result value is the number of matching data tags.
For unless mode, result value is 1.

(if|unless) dimension Edit

This feature is exclusive to Java Edition.
 
Checks if the execution is in a matching dimension.
Syntax
(if|unless) dimension <dimension> -> [execute]
Arguments
<dimension>: dimension
Dimension to test for.
It must be a resource location, which resolves into a dimension during command execution.
Result
Unparseable if the argument is not specified correctly.
In following conditions, terminates current branch when this subcommand is not at the end of the subcommand chain; fails when at the end:
  • If test doesn't pass.
When at the end of the subcommand chain, if the command is successful, both success value and result value are 1.

(if|unless) entity Edit

Checks whether one or more entities exist.
Syntax
Java Edition:
(if|unless) entity <entities> -> [execute]
Bedrock Edition:
<subcommand: Option_If_Unless> entity <target: target> [chainedCommand: ExecuteChainedOption_0]
Arguments
JE<entities>: entity
BE: target: target: CommandSelector<Actor>
The target entity/ies to test for.
Must be a player name, a target selector or a UUID[Java Edition only].
Result
Unparseable if the argument is not specified correctly.
In following conditions, terminates current branch when this subcommand is not at the end of the subcommand chain; fails when at the end:
  • If test doesn't pass.
In Java Edition, when at the end of the subcommand chain, if the command is successful:
The success value is 1.
For if mode, result value is the number of matching entities.
For unless mode, result value is 1.

(if|unless) function Edit

This feature is exclusive to Java Edition.
 
Checks if function(s) are non-void and the return value is non-zero. Terminates current branch unless the function's return value is non-zero. Doesn't change any execution context.
Unlike other conditional subcommands, this subcommand can modify the world depending on the function(s) that are tested. It also cannot be placed at the end of the subcommand chain.[1]
Syntax
(if|unless) function <function> -> execute
Arguments
<function>: function
Function to test for.
It must be a resource location or one prefixed with a #, which resolves into a function or a function tag during command execution.
Result
Unparseable if the argument is not specified correctly.
If the given function or function tag does not exist, or a function tag is given but there's no function in it, terminates the whole /execute command.
When only one function is given, if it is not macro function; and it is not void; and its return value is not 0:
  • if does nothing and unless terminates current branch.
When multiple functions are given, each function is checked and called one by one in the defined order in the tag file:
  • If the function is a macro function: Ends this subcommand execution, and if terminates current branch and unless does nothing.
  • If a function is void: Checks and calls the next function. If there's no next function, if terminates current branch and unless does nothing.
  • If a function returns a failure, or returns a success but its return value is 0: Ends this subcommand execution, and if terminates current branch and unless does nothing.
  • If a function returns a success and its return value is not 0: Ends this subcommand execution, and if does nothing and unless terminates current branch.

(if|unless) items Edit

This feature is exclusive to Java Edition.
 
Checks for a matching item in the provided inventory slots.
Syntax
(if|unless) items block <sourcePos> <slots> <item_predicate>
(if|unless) items entity <source> <slots> <item_predicate>
Arguments
<sourcePos>: block_pos
Location of a block entity to test.
Must be a block position composed of <X>, <Y> and <Z>, each of which must be an integer or a tilde and caret notation.
<source>: entity
Entity to test.
Must be a player name, a target selector or a UUID.
<slots>: item_slots
Slots to test. A string that consists of a "slot type" and an optional "slot number", in the format of <slot_type>, <slot_type>.<slot_number> or <slot_type>.*. See Slot for details.
<item_predicate>: item_predicate
Item or item tag to test for.
It must be in the format of item_id[tests](accepts item or block tags), in which tests can be omitted when they are not needed. See minecraft:item_predicate for details.
Result
Unparseable if the argument is not specified correctly.
In following conditions, terminates current branch when this subcommand is not at the end of the subcommand chain; fails when at the end:
  • If <source_pos> is unloaded or out of the world.
  • If block at <source_pos> isn't a block entity.
  • If <source> fails to resolve to one or more valid entities (named players must be online).
  • If test doesn't pass.
When at the end of the subcommand chain, if the command is successful:
The success value is 1.
For if mode, result value is the number of matching items.
For unless mode, result value is 1.

(if|unless) loaded Edit

This feature is exclusive to Java Edition.
 
Checks if chunks at a given position is fully loaded (Entity Ticking).
Syntax
(if|unless) loaded <pos> -> [execute]
Arguments
<pos>: block_pos
Position to test
Must be a block position composed of <X>, <Y> and <Z>, each of which must be an integer or a tilde and caret notation.
Result
Unparseable if the argument is not specified correctly.
In following conditions, terminates current branch when this subcommand is not at the end of the subcommand chain; fails when at the end:
  • If <pos> is out of the world.
  • If test doesn't pass.
When at the end of the subcommand chain, if the command is successful, both success value and result value are 1.

(if|unless) predicate Edit

This feature is exclusive to Java Edition.
 
Checks whether the predicate successes. See Predicate for more information.
Syntax
(if|unless) predicate <predicate> -> [execute]
Arguments
<predicate>: resource_location or inline definition
The predicate to be checked whether it evaluates to a positive result.
Must either be a resource location or an inline definition, following the same structure as predicates encoded in the SNBT format.
The command is resolved during command execution into unregistered content, or sent to the client to resolve into a client-side content.
Result
Unparseable if the argument is not specified correctly.
In following conditions, terminates current branch when this subcommand is not at the end of the subcommand chain; fails when at the end:
  • If the predicate doesn't exist.
  • If test doesn't pass.
When at the end of the subcommand chain, if the command is successful, both success value and result value are 1.

(if|unless) score Edit

Check whether a score has the specific relation to another score, or whether it is in a given range.
Syntax
Java Edition:
(if|unless) score <target> <targetObjective> (<|<=|=|>=|>) <source> <sourceObjective> -> [execute] – for comparing two scores
(if|unless) score <target> <targetObjective> matches <range> -> [execute] – for comparing one score against a range
Bedrock Edition:
<subcommand: Option_If_Unless> score <target: target> <objective: string> <operation: compare operator> <source: target> <objective: string> [chainedCommand: ExecuteChainedOption_0] - for comparing two scores
<subcommand: Option_If_Unless> score <target: target> <objective: string> matches <range: integer range> [chainedCommand: ExecuteChainedOption_0] - for comparing one score against a range
Arguments
JE<target>: score_holder
BE: target: target: CommandSelector<Actor>
A single score holder.
In Java Edition, it must be either a target selector, a player name, a UUID, or * for all score holders being tracked by the scoreboard system. Player names don't need to be of a player that is online or a player that exists and can use almost all unicode characters​[more information needed].
In Bedrock Edition, must be a player name or a target selector. It can also be quoted unique id to specified non-player entities in the objective.
JE<targetObjective>: objective
BE: objective: string: basic_string
The scoreboard objective to check under. The score of <target> or <target: target> in this objective is checked.
In Java Edition, it must be a single word. (Allowed characters include: -, +, ., _, A-Z, a-z, and 0-9) In Bedrock Edition, it must be a single word that has no space or a double-quoted string (When quoted, \ can be used to escape characters). It resolves into a scoreboard objective during command execution.
Option: (if|unless) score ... (<|<=|=|>=|>) ... or <subcommand: Option_If_Unless> score ... <operation: compare operator> ...
JE: (<|<=|=|>=|>)
BE: operation: compare operator: CommandCompareOperator
Specifies a compare operator.
Must be one of <, <=, =, >=, and >.
JE<source>: score_holder
BE: source: target: CommandSelector<Actor>
A single score holder to compare against.
In Java Edition, it must be either a target selector, a player name, a UUID, or * for all score holders being tracked by the scoreboard system. Player names don't need to be of a player that is online or a player that exists and can use almost all unicode characters​[more information needed].
In Bedrock Edition, must be a player name or a target selector. It can also be quoted unique id to specified non-player entities in the objective.
JE<sourceObjective>: objective
BE: objective: string: basic_string
A scoreboard objective. The score of <source> or <source: target> in this objective is checked.
In Java Edition, it must be a single word. (Allowed characters include: -, +, ., _, A-Z, a-z, and 0-9) In Bedrock Edition, it must be a single word that has no space or a double-quoted string (When quoted, \ can be used to escape characters). It resolves into a scoreboard objective during command execution.
Option: (if|unless) score ... matches ... or <subcommand: Option_If_Unless> score ... matches ...
JE<range>: int_range
BE: range: integer range: CommandIntegerRange
Range to compare score against.
Must be a range acceptable for 32-bit integer values. (e.g. 0 - exact match of 0. ..0 - less than or equal to 0. 0.. - more than or equal to 0. 0..1 - from 0 to 1, both inclusive.)
Result
Unparseable if the argument is not specified correctly.
In following conditions, terminates current branch when this subcommand is not at the end of the subcommand chain; fails when at the end:
  • In Java Edition, if <target> / target: target or <source> / source: target is *.
  • If test doesn't pass.
In Java Edition, when at the end of the subcommand chain, if the command is successful, both success value and result value are 1.

Example Edit

Kill all players standing on a wool:
  • execute as @a at @s if block ~ ~-1 ~ #wool run kill @s[Java Edition only]
  • execute as @a at @s if block ~ ~-1 ~ wool run kill @s[Bedrock Edition only]
Check whether scores A and B are equal: execute if score @s A = @s B

Store subcommand Edit

This feature is exclusive to Java Edition.
 

Stores the final subcommand's result or success value somewhere. It is first processed along with other subcommands in the subcommand chain, recording the location to store in. After the last subcommand (may be a condition subcommand or a run subcommand) is executed, output values are stored in the recorded location. Note that the output values of commands are always an integer. If not, they are rounded down.

There are five different modes of storage:

  1. store (result|success) block – Stores output value under one of a block's NBTs
  2. store (result|success) bossbar – Stores output value as a bossbar data
  3. store (result|success) entity – Stores output value under one of an entity's NBTs
  4. store (result|success) score – Stores output value under a target's score on an objective
  5. store (result|success) storage – Stores output value under one of a storage's NBTs

store (result|success) block Edit

Saves the final command's output value as tag data within a block entity. Store as a byte, short, int, long, float, or double. If the output value is a decimal, it is rounded first and then multiplied by <scale>.
Syntax
store (result|success) block <targetPos> <path> <type> <scale> -> execute
Arguments
<targetPos>: block_pos
Position of target block.
Must be a block position composed of <X>, <Y> and <Z>, each of which must be an integer or a tilde and caret notation.
<path>: nbt_path
Location of the desired tag to hold the value in.
<type>
Desired data size/type.
Must be one of byte, short, int, long, float, and double.
<scale>: double
Multiplier to apply before storing value, may be negative.
Must be a [Double]Double-precision floating-point number (from -(2-2-52)×21023 (≈-1.8×10308) to (2-2-52)×21023 (≈1.8×10308) ).
Result
Unparseable if the argument is not specified correctly.

store (result|success) bossbar Edit

Saves the final command's output value in either a bossbar's current value or its maximum value
Syntax
store (result|success) bossbar <id> (value|max) -> execute
Arguments
<id>: resource_location
ID of the bossbar to target for saving.
Must be a resource location for an unregistered content.
value|max
Whether to overwrite the bossbar's current value or its max value
Result
Unparseable if the argument is not specified correctly.

store (result|success) entity Edit

Save the final command's output value in one of an entity's data tags. Store as a byte, short, int, long, float, or double. If the output value is a decimal, it is rounded first and then multiplied by <scale>. Like the /data command, "/execute store" cannot modify player NBT.
Syntax
store (result|success) entity <target> <path> <type> <scale> -> execute
Arguments
<target>: entity
A single entity to store under.
Must be a player name, a target selector or a UUID. And the target selector must be in single type.
<path>: nbt_path
Location of the desired tag to hold the value in.
<type>
Desired data size/type
Must be one of byte, short, int, long, float, and double.
<scale>: double
Multiplier to apply before storing value, may be negative.
Must be a [Double]Double-precision floating-point number (from -(2-2-52)×21023 (≈-1.8×10308) to (2-2-52)×21023 (≈1.8×10308) ).
Result
Unparseable if the argument is not specified correctly.

store (result|success) score Edit

Overrides the score held by <targets> on the given <objective> with the final command's output value.
Syntax
store (result|success) score <targets> <objective> -> execute
Arguments
<targets>: score_holder
Specifies score holder(s) whose score is to be overridden.
It must be either a target selector, a player name, a UUID, or * for all score holders being tracked by the scoreboard system. Player names don't need to be of a player that is online or a player that exists and can use almost all unicode characters​[more information needed].
<objective>: objective
A scoreboard objective.
It must be a single word. (Allowed characters include: -, +, ., _, A-Z, a-z, and 0-9) It resolves into a scoreboard objective during command execution.
Result
Unparseable if the argument is not specified correctly.

store (result|success) storage Edit

Uses the <path> within storage <target> to store the output value in. Store as a byte, short, int, long, float, or double. If the output value is a decimal, it is rounded first and then multiplied by <scale>. If the storage does not yet exist, it gets created.
Syntax
store (result|success) storage <target> <path> <type> <scale> -> execute
Arguments
<target>: resource_location
Target storage container, as a resource location.
Must be a resource location for an unregistered content.
<path>: nbt_path
Location of the desired tag to hold the value in.
Must be an NBT path.
<type>
Desired data size/type.
Must be one of byte, short, int, long, float, and double.
<scale>: double
Multiplier to apply before storing value, may be negative.
Must be a [Double]Double-precision floating-point number (from -(2-2-52)×21023 (≈-1.8×10308) to (2-2-52)×21023 (≈1.8×10308) ).
Result
Unparseable if the argument is not specified correctly.

Run subcommand Edit

The run command's single argument is the command to be executed, the context variables of which may be modified by the subcommands used.

Syntax
Java Edition:
run --><command>
Bedrock Edition:
run <command: command>
Arguments
JE<command>
BE: command: command: unique_ptr<Command>
Can be any command
Technical‌[Java Edition only]
Resets the command node to the root of the command dispatcher
Information on modelling commands as chat text:
  • The command dispatcher is what starts when the player begins a message with a forward-slash (/).
  • A command node is the specific word/entry the cursor is editing, either a command or an argument.
  • The root node comes before the first word in the current command.
Result
Execute this command. Fails if <command> or command: command is failure.

More examples Edit

  • Teleport all players who have an item enchanted with Efficiency in their first hotbar slot to coordinates (0, 64, 0):
    /execute as @a if data entity @s Inventory[{Slot:0b}].tag.Enchantments[{id:"minecraft:efficiency"}] run tp @s 0 64 0[Java Edition only]
  • Create a smoke particle three blocks in front of all players:
    /execute as @a at @s anchored eyes run particle smoke ^ ^ ^3[Java Edition only]
  • Place a saddle on pigs located within 5 blocks of the executing player, and remove saddles from pigs located over 5 blocks away from the executing player:
    /execute as @e[type=pig] at @s store success entity @s Saddle byte 1 if entity @p[distance=..5][Java Edition only]
  • Make a player say "My feet are soaked!" in chat if they are located in a block of water:
    /execute as @a at @s if block ~ ~ ~ water run say "My feet are soaked!"
  • Make a player say "Score is reset" in chat if the score test is not set, eg by doing "scoreboard players reset @s test":
    /execute as @a unless score @s test = @s test run say "Score is reset"
  • Hurl all skeletons skyward who are within 3 blocks of the nearest player:
    /execute at @p as @e[type=skeleton,distance=..3] run data merge entity @s {Motion:[0.0,2.0,0.0]}[Java Edition only]
  • Kill all zombies who have no headgear:
    /execute as @e[type=zombie] unless data entity @s ArmorItems[3].id run kill @s[Java Edition only]
  • Set every player's nearbyRedSheep scoreboard objective equal to the amount of red sheep within twenty blocks:
    /execute as @a at @s store result score @s nearbyRedSheep if entity @e[type=sheep,nbt={Color:14},distance=..20]

History Edit

[hide]Java Edition
1.1317w45aReworked /execute. The syntax of /execute has been split off. See Commands/execute/Before for old syntax.
17w45bReworked /execute store.
18w02aAdded new subcommands to /execute to allow for more control over commands.
18w05aAdded /execute store (result|success) bossbar.
1.1418w43aAdded /execute (if|unless) data.
1.1519w38aAdded /execute (if|unless) predicate.
Added /execute store (result|success) storage.
1.19.322w46aAdded /execute (if|unless) biome.
1.19.423w03aAdded /execute on.
Added /execute (if|unless) dimension and /execute (if|unless) loaded.
23w04aAdded a new relation origin for /execute on.
23w06aAdded /execute summon.
Now /execute if loaded is a condition subcommand instead of a modifier-like subcommand.[2]
Pre-release 1Added /execute positioned over.
1.20.223w31aAdded /execute (if|unless) function.
1.20.2 Pre-release 1Temporarily removed syntax /execute (if|unless) function.
1.20.323w41aReintroduced syntax /execute (if|unless) function.
23w44a/execute (if|unless) function no longer always fails if all functions had no return.
1.20.524w10aAdded /execute (if|unless) items.
[hide]Bedrock Edition
1.19.10
Experiment
Upcoming Creator Features
Preview 1.19.10.20Added new /execute syntax to closer resemble that of Java Edition.
1.19.40
Experiment
Upcoming Creator Features
Preview 1.19.40.20Implemented the /execute rotated command.
Preview 1.19.40.21Implemented the /execute facing and /execute align commands.
Preview 1.19.40.23Implemented the /execute anchored and /execute in commands.
1.19.50Preview 1.19.50.23The new /execute syntax is no longer behind the "Upcoming Creator Features" experimental toggle.
1.19.70Preview 1.19.70.21Removed data: int argument from /execute <if|unless> block.

References Edit

  1. MC-267799 — resolved as "Invalid".
  2. MC-259227 — resolved as "Fixed".

Navigation Edit