Commands

Commands, also known as console commands, are advanced features activated by typing certain strings of text.

Usage
In the client, commands are entered via the chat window, which is displayed by pressing the key (default) or, $$,  key. Using the key also enters the forward-slash that commands require as a prefix, so it is a useful shortcut. The and  keys can be used to view previously entered text, including all previously executed commands. Pressing while entering commands cycles through possible commands or arguments, and can be used to auto-enter the coordinates of the block looked at before entering the chat.

When the cursor is at a location corresponding to some types of argument (such as an ID), a list of applicable values appears above the text box. If the argument is already containing some characters, the list displays only those values containing the typed command/text

Commands may also be entered in a multiplayer server's console, but are not preceded by a when entered this way. A server admin running commands in this way is often referred to as "ghosting".

Commands in command blocks can be preceded by a slash, but it is not required. Commands in a command block usually also require an argument, like a player's username.

The majority of commands are available only in the following situations:


 * In functions, as part of a data pack or add-on.
 * In a multiplayer game, entered by an operator or command block.
 * In other multiplayer games, entered by the player who opened a LAN game with cheats enabled, or is hosting their own multiplayer server
 * In singleplayer, if cheats are enabled.

Some player commands are also available in singleplayer even when cheats are not enabled.

Note: $$, in singleplayer worlds where cheats were not enabled at creation, they can be enabled on a temporary basis by opening the current game session to LAN play ( → "Open to LAN", then "Allow Cheats" button and "Start LAN World"). The player does not actually need to be on a LAN or have others join. This is not permanent but allows the use of commands until the player quits the world, and changes the player makes via commands (items spawned, etc.) are saved with the world. The player can do this each time the player starts playing the world again. Note that this disables game pausing for the duration, so while open to LAN, the player should get somewhere safe or reload their world before using the Game Menu. The player can disable the LAN world by reloading the world. To permanently enable cheats, the level.dat has to be edited.

$$, cheats can be toggled at any time in the "Game" tab of the settings menu. Enabling cheats in a world permanently prevents players from unlocking achievements in that world, even if cheats are later turned off.

Relative world coordinates: Tilde notation
Ordinarily, position arguments are expressed as a set of three absolute world coordinates, each number representing a distance along an axis from the world origin.

Each coordinate can alternatively be expressed as a relative world coordinate, written in tilde notation. A number following a tilde (~) describes an offset from execution position along one of the world axes, and a lone tilde assumes an offset of 0; for example, the position  means "10 blocks east (+X) and 30 blocks north (–Z) of here."

Essentially,  is shorthand for the command's current position.

Relative world coordinates can mix with absolute coordinates; for example, keeps the sender's X and Z positions unchanged but teleports them to an absolute height of 64 blocks.

The command can update a command's current position, changing the meaning of.

$$, pressing replaces the crosshair with a display of these three directions: +X in red, +Y in green, +Z in blue (westwards, upwards, and southwards, respectively).

Local coordinates: Caret notation
The other way to describe positions is with local coordinates, written entirely in caret notation. Like relative coordinates, these describe positions relative to where a command is executed from, but with different directions. A number following a caret (^) is an offset within a moving, entity-centric frame: This is a coordinate system which is centered at the sender's feet, with +Xlocal directed to its left, +Ylocal directed upwards, and +Zlocal directed in the direction it is facing. (Note that an entity with rotation  has its local frame aligned with the world frame.)
 * Described in other terms, these coordinates express ^ΔSway ^ΔHeave ^ΔSurge

''For example, teleports the player 5 blocks forwards. If they turn around and repeat the command, they are teleported back to where they started.''

$$, pressing + displays the +Zlocal direction for all entities as a blue ray centered on their heads

Local coordinates cannot be mixed with world coordinates (e.g.,  ), and attempting so alerts the typist, "Cannot mix world & local coordinates (everything must either use ^ or not)." So such a command fails or cannot be executed.

A command's execution position, rotation, dimension, and anchor all change the effect of using. These can be updated by the command.

Target selectors
In most commands where a player may be specified as an argument, it is possible to "target" one or more players satisfying certain conditions instead of specifying players by name. To target players by condition, choose a target selector variable and, optionally, one or more target selector arguments to modify the conditions to be satisfied.

For example, to change the game mode of all players on team Red to creative mode, instead of specifying them by name individually:

Target selector variables
A target selector variable identifies the broad category of targets to select. There are five (or, $$, seven) variables:




 * Targets the nearest player. When run by the console, the origin of selection is (0, 0, 0). If there are multiple nearest players, caused by them being precisely the same distance away, the player who most recently joined the server is selected.


 * Target selector arguments may be used to specify what category of players to select the nearest player from. For example,  targets the nearest player on team Red even if there are other players closer.


 * The  or  target selector argument can be used to increase the number of nearest players targeted (for example,   or   targets the three nearest players, respectively).

$$,  ignores dead players.




 * Targets a random player.


 * Target selector arguments may be used to specify what category of players to select a random player (or more) from. For example,  targets a random player from team Red. Whereas   targets three random players.


 * $$, one cannot use  to target entities via the   selector argument. To select a random entity, use   instead.
 * $$,  ignores dead players.




 * Targets every player (alive or dead) by default unless Target selector arguments are used. For example,  only targets all players on team Red.




 * Targets all alive entities in loaded chunks (Includes players unless if  is specified).


 * Target selector arguments may be used to specify what category of entities to target from. For example,  only targets cows.




 * Targets the entity (alive or dead) that executed the command. It does not target anything if the command was run by a command block or server console.


 * Target selector arguments may be used to specify whether the executor is actually eligible to be targeted. For example,  targets the executor of the command if the executor was a cow on team Red.




 * Target the player's agent only.


 * Target selector arguments may be used to target the player's agent. For example,  teleports the player's agent only to the specified location.




 * Target all agents. Works only if more than one agent exists.


 * Target selector arguments may be used to target all agents. For example,  removes all agents.

Target selector arguments
After a target selector, optional arguments can be used to narrow down the set of targets to a group that also matches certain criteria. When used with  or , arguments narrow down the targets from the full list to a specific group. When used with  or , the nearest or random player is selected from the group. When used with, the player using the command is targeted only if they would be in the narrowed group.

Argument-value pairs appear within square brackets after the target selector variable, separated by commas:



Arguments and values are case-sensitive. Spaces are allowed around the brackets, equal signs, and commas, except in between the target variable and the first bracket. Commas must be used to separate argument-value pairs.

If there are multiple argument-value pairs, they all must be satisfied to add a potential target to the group. (In other words, they are AND-ed together).


 * Position arguments


 * Define a position in the world the selector starts at, for use with the  argument or the volume arguments, ,   and  . Defining the position alone can be used with a target selector that selects the nearest entity from those coordinates, but it otherwise has no use, so applying it (and only it) to   still selects all entities in the same dimension.
 * The positional components are doubles, allowing for values like, and they are not center-corrected, meaning   is not corrected to   - tilde notation is available for selector argument coordinates.
 * The positional components are doubles, allowing for values like, and they are not center-corrected, meaning   is not corrected to   - tilde notation is available for selector argument coordinates.


 * Selecting targets by distance


 * - Filter target selection based on their Euclidean distances from some point, searching for the target's feet (a point at the bottom of the center of their hitbox). If the positional arguments are left undefined, radius/i is calculated relative to the position of the command's execution. Only unsigned values are allowed.
 * $$, ranges are supported to select a specific region:
 * — Target all entities exactly ten blocks away.
 * — Target all entities more than eight blocks, but less than 16 blocks away (inclusive).
 * $$,  represents the maximum range to find entities and   represents the minimum. As such:
 * — Target all entities exactly ten blocks away.
 * — Target all entities from 8 to 16 blocks away.




 * - Filter target selection based on their x-difference, y-difference, and z-difference from some point, as measured from the closest corner of the entities' hitboxes[JE] or by their feet.[BE]
 * This can be interpreted as creating a rectangular volume defined by an initial position (,,) and diagonal vector (,,), then selecting all entities whose hitboxes are at least partially contained by that volume ($$, whose feet are within that volume). If the positional arguments are left out, the selection is interpreted as originating from the position of the command's execution. Any values are allowed, including signed and fractional numbers.
 * Note that, ,  specify signed differences from the given coordinate. They do not specify a separate coordinate, nor do they extend in both the positive and negative directions.
 * Examples $$:
 * — Select all entities whose hitbox collides with the block region (1~5, 2~7, 3~9) (or, mathematically speaking, the region that is {(x,y,z)∈R3|x∈[1.0,5.0),y∈[2.0,7.0),z∈[3.0,9.0)}).
 * — Select all entities whose hitbox contains the point (1,2,3).
 * Examples $$:
 * — Select all entities whose feet are within the block region (1~5, 2~7, 3~9).
 * — Select all entities whose feet contains the point (1, 2, 3).
 * It is possible to combine selection by distance and selection by volume, in which case the command select targets only within the overlap of both regions (within a certain radius/I of the volume's initial point and not outside the defined volume).
 * $$, entities without a hitbox (for example, armor stands with ), may not be selected.


 * Selecting targets by scores


 * - Filter target selection based on their scores in the specified objectives.
 * All tested objectives are in a single tag, with a list of individual score selectors between braces afterward. The selectors inside the braces support ranges.
 * — Select all entities with a score in objective myscore of exactly ten.
 * — Select all entities with a score in objective myscore of between ten and 12 (inclusive).
 * — Select all entities with a score in objective myscore of five or greater.
 * — Select all entities with a score in objective myscore of 15 or less.
 * — Select all entities with a score in objective foo of exactly ten, and a score in objective bar of between one and five (inclusive).


 * Selecting targets by team


 * - Filter target selection to those who are on a given team.
 * — Filter to those who are not on a given team.
 * — Filter to those who are teamless.
 * — Filter to those who have some team.


 * Limiting and sorting target selection


 * - Limit the number of targets selected to be no higher than the given value.
 * When using the variables  and , this argument defaults to one. Applying the   argument to them may artificially increase the number of nearest or random targets selected. When applying this argument to   or  , this argument returns only a limited number of targets.
 * [JE] - Limit the number of targets, and specify selection priority.
 * — Sort by increasing distance. (Default for,  [BE],  [BE])
 * — Sort by decreasing distance.
 * — Sort randomly. (Default for )
 * — Do not sort. (Default for [JE],  [JE])
 * Examples $$:
 * or  — Select the nearest three players.
 * — Select the furthest four players.
 * or  — Select two players, chosen randomly.
 * Examples $$:
 * — Select the nearest three players.
 * — Select the furthest four players.
 * — Select two living players, chosen randomly.


 * Selecting targets by experience level


 * - Filter target selection based on their experience levels. This naturally filters out all non-player targets.
 * $$, this selector supports ranges:
 * — Select all players who have exactly ten levels.
 * — Select all players who have between eight and 16 levels (inclusive).
 * $$,  represents the maximum level to search for and   represents the minimum. As such:
 * — Select all players who have exactly ten levels.
 * — Select all players who have between eight and 16 levels (inclusive).


 * Selecting targets by game mode


 * — Filter target selection to those who are in the specified game mode.
 * — Filter target selection to those who are not in the specified game mode.
 * This naturally filters out all non-player targets. Permitted values for  are,  ,  , and  . $$, the shorthand values   and  ,   and  , and   and   may be used for Adventure mode, Creative mode, and Survival mode respectively.
 * Examples $$:
 * — Select all players who are in Survival mode.
 * — Select all players who are not in Spectator mode.
 * Examples $$:
 * or  or   — Select all players who are in Survival mode.
 * or  or   — Select all players who are not in Creative mode.


 * Selecting targets by name


 * — Filter target selection to all those with a given name.
 * — Filter target selection to all those without a given name.
 * This is a string, so spaces are allowed only if quotes are applied. This cannot be a JSON text compound.
 * - Select all entities that are not named "Steve".


 * Selecting targets by vertical rotation


 * — Filter target selection based on their pitch, or more specifically their declination from the horizon, measured in degrees. Values range from -90 (straight up) to 0 (at the horizon) to +90 (straight down).
 * $$, this argument supports ranges:
 * — Select all entities that are looking directly at the horizon.
 * — Select all entities that are looking between 30&deg; and 60&deg; (inclusive) below the horizon.
 * — Select all entities that are looking 45&deg; or more below the horizon.
 * — Select all entities that are looking at or above the horizon.
 * $$,  represents the maximum x-rotation value to search for and   represents the minimum. As such:
 * — Selects all entities that are looking directly at the horizon.
 * — Selects all entities that are looking between 30&deg; and 60&deg; (inclusive) below the horizon.
 * — Select all entities that are looking 45&deg; or more below the horizon.
 * — Select all entities that are looking at or above the horizon.


 * Selecting targets by horizontal rotation


 * — Filter target selection based on their rotation in the horizontal XZ-plane, measured clockwise in degrees from due south (or the positive Z direction). Values vary from -180 (facing due north) to -90 (facing due east) to 0 (facing due south) to +90 (facing due west) to +180 (facing due north again).
 * $$, this argument supports ranges, and the maximum can reach values over 180. Some examples:
 * — Select all entities that are facing due south.
 * — Select all entities that are facing 45&deg; west of south.
 * — Select all entities that are facing in the 90&deg; between due north and due east (inclusive).
 * — Select all entities that are facing in the 90&deg; between due east and due south (inclusive).
 * — Select all entities that are facing between due east and due west (inclusive), through south.
 * — Select all entities that are not facing at all east.
 * $$,  represents the maximum y-rotation value to search for and   represents the minimum. As such:
 * — Select all entities that are facing due south.
 * — Select all entities that are facing 45&deg; west of south.
 * — Select all entities that are facing in the 90&deg; between due east and due south (inclusive).
 * — Select all entities that are not facing at all east.


 * Selecting targets by type


 * — Filter target selection to those of a specific entity type.
 * — Filter target selection to those not of a specific entity type.
 * The given entity type must be a valid entity ID or entity type tag used to identify different types of entities internally. The namespace can be left out if the ID is within the  namespace. (For example,   for creepers,   for regular minecarts,   for primed TNT, etc.) Entity IDs or tags are case-sensitive.
 * When using the  parameter, this argument defaults to the type  . Defining a type for this parameter can filter the random selection to other entities.
 * — Select all skeletons.
 * — Select all entities except chickens and cows.
 * — Select all skeletons, wither skeletons, and strays.
 * Note that  fails because a given entity cannot be both a pig and a cow.


 * Selecting targets by family


 * — Filter target selection to those of a specific entity family.
 * — Filter target selection to those not of a specific entity family.
 * The given entity family can be any string. It does not include a namespace. These entity families are defined in an entities type_family behavior component. Default values used by the vanilla behavior pack include among others more broad terms like,  ,   and   as well as more specific, smaller families like   and   and single-mob families like  ,   and  . A single entity can be part of multiple families.
 * — Select all skeletons, wither skeletons and strays.
 * — Select all mobs that are not also monsters (so for example cows, chickens, pigs, but not zombies or skeletons).
 * — Select all monsters that are also undead (that includes monsters like zombies and skeletons, but not creepers or endermen).


 * Selecting targets by data tag


 * — Filter target selection to those that have at least one tag of the given name.
 * — Filter to those that have no tags of the given name.
 * — Filter to those that have exactly zero tags.
 * — Filter to those that have at least one tag.
 * Multiple tag arguments are allowed. All argument specifications must be fulfilled for an entity to be selected.
 * — Select all entities that have tags a and b, but not tag c.
 * — Select one random player who has tag a.


 * Selecting targets by NBT


 * — Select all targets that have the specified NBT. The NBT is written in its command definition.
 * — Select all targets that does not have the specified NBT.
 * For example:
 * — Select all players on the ground.
 * — Select all sheep that are dyed white.
 * — Selects all slime ball item entities.
 * is the same as . The latter is simpler and reduces CPU load.
 * Note: When matching the string form of namespaced IDs within a tag, the namespace cannot be omitted.
 * Hence  cannot find any item entities as the  field always contains a namespaced ID-converted string.


 * Selecting targets by advancements


 * — Select all targets that match the specified advancement and value.
 * — Select all targets that match the specified advancement and value.
 * The argument name is the advancement ID (namespace can be left out when namespaced ). The value is true or false.
 * For advancements with one criterion, testing for that criterion always gives the same results as testing for the advancement.
 * — Selects players who have achieved the advancement minecraft:story/form_obsidian.
 * — Selects players who haven't achieved the advancement minecraft:story/form_obsidian.
 * — Selects players who had armored with iron helmet. The selected players needn't be wearing iron helmet when selected, and needn't have achieved the advancement minecraft:story/obtain_armor.
 * is the same as.


 * Selecting targets by predicate


 * — Select all targets that match the specified predicate.
 * — Select all targets that fail to match the specified predicate.


 * Since 19w38a, selectors can use predicates in the argument.
 * — Selects players who match the example:test_predicate predicate.
 * — Selects entities who do not match the minecraft-wiki:smart_entity predicate.

Data tags
A data tag is a tree-shaped data structure that can be described starting with attribute-value pairs enclosed in curly braces. One common usage of data tags $$ is in commands, used to specify complex data for any entity.

A data tag consists of zero or more attribute-value pairs delimited by commas and enclosed in curly braces. Each attribute-value pair consists of an attribute name and the attribute's value, separated by a colon. Some values, however, may themselves contain attribute-value pairs, allowing a data tag to describe a hierarchical data structure.


 * Example:

The data structures that data tags describe are the same ones used in Minecraft's save files. These data structures are described in other articles and commands expect data tags to use the same attribute names (which are case-sensitive):

The defined data structures also expect the values to be of the correct type.

Some commands may require that a number's type be specified by adding a letter (B, S, L, F, D) to the end of the value. For example,  for a short,   for a float, etc. (This doesn't work with I for int.) The letter can be uppercase or lowercase. When no letter is used and Minecraft can't tell the type from context, it assumes double if there's a decimal point, int if there's no decimal point and the size fits within 32 bits, or string if neither is true. A square-bracketed literal is assumed to be a list unless an identifier is used:  for an int array and   for a long array.

When commands such as are used to match data tags, they check only for the presence of the provided tags in the target entity/block/item. This means that the entity/block/item can have additional tags and still match. This is true even for lists and arrays: the order of a list is not acknowledged, and as long as every requested element is in the list, it matches even if there are additional elements.

Raw JSON text
The and  commands use the raw JSON text format to display texts.

Also, Some values of arguments in NBT structures are using JSON format.

ID arguments in Java Edition
Many commands have arguments that identify particular types of blocks, items, entities, advancements, bossbars, effects, enchantments and so on. In the command syntax below, these typically appear as elements named,  , or the like, which are replaced with identifiers such as   in the examples. These IDs all have namespaces. All original Minecraft contents are namespaced  while contents from mods or data packs have other namespaces. Namespace prefix of IDs namespaced  can be omitted for most situations; however, in certain cases, such as NBT data tag matching, full namespaced ids are required.

A single  argument looks like this:

The format of  parameters is , in which block states and data tags can be omitted when they are not needed.
 * Namespaced ID is required (though if namespace isn't set it defaults to ).
 * In the context of "conditions"/testing for blocks, it can also be the namespace ID of block tag with the prefix of, such as.
 * Block states are inside, comma-separated and must be properties/values supported by the blocks. They are optional.
 * is a syntax error, because  doesn't have.
 * is a syntax error, because 's   is a number between 0 and 15.
 * Data tags are inside . It's optional.
 * In the context of "conditions"/testing for blocks, only the states provided are tested.
 * If command tests, it checks only power, but ignores other states such as.
 * In the context of setting blocks, any states provided are set, but anything omitted retain their default values, depending on the block.
 * If command sets, it is set   to 15, but   is a default value (in this case, set to  ).

A single  argument that looks like this:

The format of  parameters is , in which data tags can be omitted when not needed.
 * Namespaced ID is required (though if namespace isn't set it defaults to ).
 * Data tags are inside . It's optional.

List of argument types in Java Edition
These are the argument types $$.

List and summary of commands
The table below summarizes all commands, including upcoming ones.

Debug commands
These developer exclusive commands were accidentally left in the iOS release of Bedrock Edition 1.2.13. They were removed in Bedrock Edition 1.2.14.

Syntax
$$:
 * {| class="wikitable" style="text-align:center" data-description="Syntax"

! Syntax !! Meaning
 * || Enter this literally, exactly as shown.
 * || An argument that should be replaced with an appropriate value.
 * || This entry is optional.
 * || (Required) Pick one of the entries that is shown.
 * || (Optional) Pick one of the entries that is shown.
 * || Another sub-command is required.
 * }
 * || (Required) Pick one of the entries that is shown.
 * || (Optional) Pick one of the entries that is shown.
 * || Another sub-command is required.
 * }
 * || Another sub-command is required.
 * }

$$:
 * {| class="wikitable" style="text-align:center" data-description="Syntax"

! Syntax !! Meaning
 * || Enter this literally, exactly as shown.
 * || An argument that should be replaced with an appropriate value.
 * || Pick one of the entries that is shown.
 * || This entry is required.
 * || This entry is optional.
 * }
 * || This entry is required.
 * || This entry is optional.
 * }
 * || This entry is optional.
 * }

Success Conditions

 * A command's Success Conditions must be met in order for the game to consider the command "successful". This is used to determine a variety of things, such as the output of a redstone comparator feeding from a command block with a command. Note that not all "successful" commands actually do something, and not all "failed" commands fail to do something useful.

Restrictions

 * Describes restrictions on who can use the command or in what context.
 * None: The command can be used by any player in any world. The following commands have no restrictions:, , , and.
 * Operator: The command may be used only by an operator or in singleplayer mode with cheats enabled. On multiplayer servers, the results of these commands are broadcast to other ops online.
 * Multiplayer: The command is available only on a multiplayer server. The following commands are restricted to multiplayer servers:, , , , , , , , , , , , , ,.
 * No multiplayer commands permit target selectors in arguments.
 * Except for, multiplayer commands cannot be used in command blocks.
 * Many of these commands can be used on players who have never been to the server, or even on names that are not (or cannot be) registered as Minecraft accounts.
 * No command blocks: The command cannot be executed by a command block.