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 /  /, 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 owner 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 singleplayer, entered by player or command block if cheats are enabled.
 * In functions or scripts, as part of a data pack or add-on.
 * In a multiplayer game, entered by an operator or command block.
 * In a multiplayer server, entered in the console.
 * In other multiplayer games, entered by the player who opened a LAN game with cheats enabled, or is hosting their own multiplayer server
 * In a WebSocket server, if cheats are enabled.

Some player commands are also available 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.

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.

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.
 * }

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
These are the argument types.

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 has no restriction.
 * Cheat only: When executed by a player, the command is available only if cheats is enabled.
 * $$, when cheats is disabled, these commands can't be used by players even if they have a high permission level. $$, if players have a high enough permission level, they can use corresponding commands no matter whether cheats is allowed.
 * Dedicated server only: The command is available only on a dedicated server.
 * No command blocks: The command cannot be executed by a command block.

Permission level

 * Permission level is used to describe permissions on what commands can be used by an executor. For example, $$, can't be executed in a command block, because this command requires executor to have permission of level 3, while command blocks have permission of only 1 level.


 * $$, permission level can be 0, 1, 2, 3, and 4.
 * A command block or a minecart with command block has permission level of 2.
 * The console of a server has permission level of 4.
 * A function has permission level of 2 (but it can be changed in server.properties).
 * For a player:
 * If the player is an op in dedicated server, their permission level is specified in ops file.
 * If the player is in a singleplayer world or is the owner of a LAN world, and cheat is enabled, permission level is 4.
 * If the player is in a cheat-allowed LAN world, permission level is 4.
 * Otherwise, permission level is 0.


 * $$, permission level can be 0, 1, 2, 3, and 4.
 * A command block or a minecart with command block has permission level of 1.
 * The console of a server has permission level of 4.
 * A function as well as a script in Add-ons has permission level of 1.
 * For a player:
 * If in dedicated server, the player's "Operator Commands" option is enabled in the "Player Permission" screen, their permission level is 1 by default (which can be changed in server.properties).
 * If in a singleplayer world or a LAN world, the player's "Operator Commands" option is enabled in the "Player Permission" screen, permission level is 3.
 * Otherwise, the player's permission level is 0.


 * Note that command permission level differs from permission level in pause menu screen and "Player Permission" screen $$, which includes Visitor/Member/Operator/Custom. However, operator in singleplayer world must have command permission level of 3, because its Operator Commands is enabled. Similarly, visitors and members have a command permission level of 0.

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

Developer commands
Developer commands are only enabled in the development and testing environment of the game. In release versions, players cannot see and execute these commands.

Agent commands
Superseded by