What the /execute command does
The /execute command runs another command in a context you control. Instead of running a command as yourself, standing where you stand, you can run it as another entity, from another position, facing another direction, or only when a condition is true. It is the backbone of most custom maps, datapacks, and command-block contraptions in Minecraft.
On its own, /execute does nothing visible. It sets up who runs the final command, where it runs, and whether it runs at all. The real work happens in the command that follows run at the end of the chain.
This guide covers the modern syntax introduced in Java Edition 1.13 and brought to Bedrock in 1.19.50. On older versions the syntax is different, and most of the examples below will not parse.
How to run /execute
You need permission to use commands. In single-player, turn on cheats when you create the world, or open it to LAN with cheats allowed. On a server you need operator status (permission level 2 or higher). Command blocks run at the required permission level automatically, so anything that works in chat works in a command block.
You type /execute followed by one or more subcommands, then run and the command you actually want to fire. The chat box shows in-game suggestions as you type, which is the fastest way to learn the order of the parts.
The execution context
Every command runs inside a context made of four things: the executor (the entity the command treats as @s), the position, the rotation, and the dimension. When you type a command yourself, the context is you. You are the executor, your coordinates are the position, your facing is the rotation, and your current dimension is the dimension.
The point of /execute is to change one or more of those values before the final command runs. Each subcommand edits part of the context, and you can stack as many as you need. The chain reads left to right, and each subcommand passes its modified context to the next one.
The main subcommands
as
as <targets> changes the executor. The final command treats the chosen entity as @s, but the position and rotation stay where they were. If you target more than one entity, the rest of the chain runs once for each one. /execute as @a run say hi makes every player say hi in chat.
at
at <targets> moves the position, rotation, and dimension to match the target, without changing who @s is. The classic pairing is as @a at @s, which loops over every player and moves the context to each one in turn. /execute as @a at @s run particle heart ~ ~1 ~ spawns a heart above every player’s head.
positioned
positioned <x y z> sets an exact position, and positioned as <targets> copies a position from an entity without taking its rotation. Relative coordinates with ~ are measured from the current context, so you can offset step by step.
rotated
rotated <yaw pitch> sets the facing used by local ^ coordinates and by commands that care about direction. rotated as <targets> copies an entity’s facing.
facing
facing <x y z> points the rotation at a block position, and facing entity <target> <feet|eyes> points it at an entity. This is how you make a command aim at something, such as firing a projectile toward the nearest player.
align, anchored, and in
align <axes> snaps the position down to the block grid on the axes you list, which helps when you need whole-block coordinates. anchored <eyes|feet> decides whether ^ coordinates and facing measure from the entity’s eyes or feet. in <dimension> switches the dimension, for example in the_nether or in the_end.
Conditions: if and unless
if lets the chain continue only when a test passes. unless is the opposite: it continues only when the test fails. Both can check several kinds of state:
if block <pos> <block>tests a single block.if blockscompares two regions, useful for detecting a built structure.if entity <selector>passes when at least one entity matches.if scorecompares scoreboard values.if predicate <id>runs a datapack predicate (Java only).
You can chain conditions together. /execute if entity @e[type=creeper] if block ~ ~-1 ~ grass_block run say danger only fires when both tests pass. Without a run at the end, an if check returns its result as a number, which is how you read state into other commands.
Storing results with store
store result and store success capture the output of the final command and write it somewhere. store result saves the command’s return value, while store success saves 1 or 0 depending on whether the command ran successfully. You can store into a scoreboard, into entity or block data (Java), or into a bossbar.
A common use is reading a value onto a scoreboard. /execute store result score @s daytime run time query daytime writes the current world time onto the player’s daytime score, which you can then test with if score.
run
run ends the chain and takes the command you want to execute. Everything after run is a complete command, written exactly as you would type it on its own, minus the leading slash. Only one run is allowed, and it has to come last. In Java Edition you can leave run off entirely if you only want the return value of a trailing if or unless test.
Putting it together
The power comes from stacking subcommands. Read this one left to right: /execute as @a at @s if block ~ ~-1 ~ water run effect give @s dolphins_grace 5 0. It loops over every player, moves to each player’s position, checks whether the block under their feet is water, and gives a short Dolphin’s Grace effect to the ones standing in it. Each subcommand shifts or narrows the context until the final effect command fires only where it should.
Order matters. as @a at @s is not the same as at @s as @a. The first sets the executor, then moves to that executor. The second moves to the original @s first, which may not be the entity you expect. When a chain misbehaves, the order of as and at is the first thing to check.
Common mistakes
The most frequent error is confusing as and at. as changes who the command treats as @s, and at changes where it happens. You almost always want both together when you loop over players or mobs.
Another is forgetting that relative coordinates follow the context. After at @s, a ~ ~ ~ means the target’s position, not yours. Local ^ coordinates depend on rotation and on the anchored setting, so a projectile that fires in the wrong direction usually needs a rotated or anchored fix.
Java and Bedrock differences
Bedrock adopted the Java-style subcommand syntax in 1.19.50, so the core structure matches. The gaps come from features Bedrock does not have. Predicates are Java only, so if predicate does not exist on Bedrock. Bedrock also has no /data command, so storing into or testing entity NBT works differently, and several store targets that rely on data are Java only. When you copy a command between editions, the subcommand skeleton usually carries over, but anything touching predicates or NBT needs a second look.
Frequently asked questions
What does /execute do on its own?
Nothing visible. It sets the context (executor, position, rotation, dimension) and conditions for the command that follows run. With no run and no trailing condition, it does nothing.
What is the difference between as and at?
as changes the executor, the entity treated as @s. at changes the position, rotation, and dimension. They are independent, and you often use both in the same command.
Why does my command run multiple times?
If a subcommand like as @a matches several entities, the rest of the chain runs once for each match. That is intended. Narrow the selector if you want it to fire only once.
Do I need cheats on to use /execute?
Yes. You need cheats enabled in single-player or operator permission on a server. Command blocks run it without extra setup.
Can I use /execute on Bedrock?
Yes, from version 1.19.50 onward, with the same subcommand syntax as Java. Older Bedrock versions used a different format that will not match these examples.
Can I chain more than one condition?
Yes. You can stack as many if and unless checks as you want, in any order, before run. The chain reaches the final command only if every check passes.
Where to go next
The fastest way to get comfortable is to build a chain one subcommand at a time and test after each addition. Start with as @a at @s run say here, confirm it targets the right entities, then add a condition, then the real command. Once the order of as and at clicks, the rest of the subcommands are small variations on the same idea.