The /execute command runs another command with a different executor, position, rotation, or condition attached, using subcommands like as, at, positioned, if, unless, and finally run to trigger the actual command. It’s the backbone of advanced redstone contraptions, custom game modes, and command-block automation, because it lets one command react to a condition and act on behalf of a specific entity instead of just yourself.
This is a single-command deep dive, not a broad list. If you want a wider set of useful commands first, see our best Minecraft commands for creative mode, or check the full Minecraft commands list for complete syntax on every command. This post exists purely to explain /execute itself: its subcommands, how chaining and “forking” actually work, and real one-liners you can copy straight into a command block.
Quick Answer
- What it does:
/executewraps another command in modifiers and conditions, so the wrapped command can run as a different entity, at a different position, or only if something is true. - The chain always ends in
run. Every subcommand beforerunsets up context or a condition;runis what actually fires the target command. asandatchange who and where.aschanges which entity the rest of the chain acts as;atmoves the execution position to that entity’s location.ifandunlessgate the command. They check a condition (a block, a score, an entity, and more) and only let the chain continue if that condition passes (if) or fails (unless).- You need operator-level permission.
/executerequires permission level 2 on Java Edition and permission level 1 on Bedrock Edition, the same level most cheat commands need. It works from chat if you’re an operator at that level, or from a command block regardless of your own permission level.
What /execute Actually Does (and Why It’s Different from a Normal Command)
A normal command runs exactly as you typed it, from your own position, as yourself. /execute breaks that assumption apart.
With /execute, you can run a command as if a specific mob typed it, from that mob’s exact coordinates, only if a certain block is nearby, and only log the result into a scoreboard instead of chat. None of that is possible by just typing the target command directly.
That flexibility is why /execute shows up in almost every serious redstone build, custom minigame, or datapack. It’s less a single command and more a small scripting language bolted onto the chat bar.
The /execute Subcommand Categories
Every /execute chain is built from four kinds of pieces, and they always appear in the same relative order: modifiers first, conditions next, an optional result-store, and run last.
| Category | Subcommands | What they do |
|---|---|---|
| Modifier (context) | as, at, in, positioned, rotated, anchored, facing, align, summon, on | Change who the command runs as, or where/how it runs from |
| Condition | if, unless | Gate the chain on whether something is true or false |
| Result-store | store | Save the outcome of the final command instead of (or alongside) running it normally |
| Terminator | run | Actually fires the target command; must be the last subcommand in the chain |
Modifier subcommands (as, at, positioned, rotated, facing, align, anchored, in, on, summon)
as <targets> changes which entity (or entities) the rest of the chain executes as. This matters for anything that depends on the executor, like @s selectors further down the chain.
at <targets> moves the execution position and rotation to match the target entity, without changing who the command runs as. positioned and rotated do something similar but let you set an exact position or rotation directly instead of copying it from an entity.
facing and anchored control where the execution is considered to be “looking,” which matters for anything using relative ^ coordinates. align snaps the execution position to whole numbers on chosen axes, and in changes which dimension the rest of the chain runs in. on moves execution to a related entity, such as a vehicle’s passenger or an attacker’s target, and summon spawns a new entity and executes as it in one step.
Condition subcommands (if, unless)
if <condition> only lets the chain continue if the condition is true. unless <condition> is the mirror image: it only continues if the condition is false.
Four condition types work on both editions: block (a specific block at a position), blocks (comparing two regions), entity (whether a selector matches anything), and score (a scoreboard comparison). Eight more are Java Edition only: biome (which biome the execution is in), data (checking NBT data), dimension (which dimension the execution is in), function (a function’s return value), items (checking an inventory slot range), loaded (whether a position’s chunk is loaded), predicate (a custom-defined condition), and stopwatch (a running command-block clock).
The store subcommand
store result or store success saves the outcome of the final command instead of just letting it happen silently. You can store that outcome into a scoreboard score, a block’s data, an entity’s data, or a storage location, depending on what you’re building.
This is what makes /execute useful for genuinely programmatic setups, like tracking how many blocks a /fill command actually placed, or recording whether a teleport succeeded.
run, where the chain actually fires
run is always last. Everything before it sets up who, where, and under what condition; run is the point where the actual target command (the one you ultimately wanted to execute) fires.
If you forget run, nothing happens beyond the setup itself. This is the single most common beginner mistake with this command.
How Subcommand Chaining and “Forking” Work
Subcommands process strictly left to right. Each one narrows or changes the context that the next subcommand (and eventually run) operates in.
The part that trips people up is what happens when a modifier like as targets more than one entity. When that happens, everything after it in the chain runs once per matching entity, independently. This branching behavior is commonly called “forking,” and it’s the reason a single /execute as @a ... command can affect every player on the server as if you’d typed the rest of the command once for each of them.
Here’s a concrete example. Take /execute as @a at @s run tp ~ ~10 ~. The as @a selects every player, which forks the chain into one execution per player.
For each of those forks, at @s moves execution to that specific player’s location, and run tp ~ ~10 ~ teleports that player 10 blocks up from where they’re standing. The net effect is that every player on the server gets teleported up 10 blocks from their own current position, not from yours.
If you swapped at @s for a fixed set of coordinates instead, every player would teleport to the exact same point, since the forking would still happen for as @a, but the position would no longer be tied to each individual player.
Practical /execute One-Liners
These are worked examples using verified vanilla syntax. Test each one in a private world or on a command block before wiring it into anything permanent.
Teleporting or effecting entities that meet a condition
To give speed to any player standing on a diamond block:
/execute as @a at @s if block ~ ~-1 ~ minecraft:diamond_block run effect give @s minecraft:speed 5 1
This forks once per player (as @a), moves to each player’s position (at @s), checks the block directly beneath them, and only fires the effect give if that check passes.
Redstone or command-block triggers using if block or if score
A command block wired to a pressure plate can check a specific block state instead of relying purely on redstone timing:
/execute if block 100 64 200 minecraft:redstone_ore run setblock 100 65 200 minecraft:lit_redstone_lamp
For scoreboard-driven automation, if score compares a tracked value:
/execute if score @s deaths matches 5.. run tellraw @s {"text":"You have died five or more times."}
The 5.. range syntax means “5 or greater,” which is standard Minecraft range notation and works the same way in other range-based arguments.
Running a command at another entity’s position
To strike lightning at every creeper currently loaded:
/execute at @e[type=creeper] run summon minecraft:lightning_bolt
This moves execution to each matching creeper’s location in turn (forking once per creeper) and summons the lightning bolt there, without needing to know any coordinates in advance.
Common /execute Mistakes
Forgetting run. Without it, every modifier and condition you set up has nothing to actually trigger. The chain silently does nothing.
Putting subcommands in the wrong order. run must be last, and conditions generally make more sense placed after the modifiers that set up the context they’re checking. Reordering things can change what a condition actually tests.
Misunderstanding forking. A single /execute as @a ... line isn’t one command, it’s effectively one command per matching entity. Builders sometimes expect a single global effect and get surprised when the command fires independently for every player or mob that matches the selector.
Assuming every condition type works on both editions. Only block, blocks, entity, and score exist on both Java and Bedrock. The other eight, including biome, data, dimension, and predicate, are Java Edition only. If a specific condition doesn’t seem to work, check whether it’s supported on your edition before assuming your syntax is wrong.
Frequently Asked Questions
The as subcommand changes which entity the rest of the execute chain runs as. This matters for anything relying on the executor, such as a following at subcommand or a selector like @s further down the chain.
If only lets the rest of the chain run when the condition is true, while unless only lets it run when the condition is false. They check the same condition types; they just gate on opposite outcomes.
No, you can type /execute directly in chat as long as you have permission level 2 on Java Edition or level 1 on Bedrock Edition, the same level most cheat commands require. Command blocks are useful for automation and don’t require the player who placed them to have operator status, but they aren’t required just to run the command manually.
Yes. You can stack multiple modifier and condition subcommands in a single chain before the final run, and each if or unless in that chain must pass for the command to fire. Just remember that run always has to be the last subcommand.
Once /execute clicks, most of the redstone and command-block builds that used to look like black magic start making sense, since almost all of them are some combination of “as this entity,” “at this position,” “if this is true,” then “run this.” For the full syntax of every other command referenced above, our Minecraft commands list has the complete reference.
