Tag (Java Edition)

Tags (also called registry tags) in data packs allow players to group different game elements together.

Tags act as references to groups of registry entries, letting Minecraft treat multiple items, blocks, or entities as a single category. For example, the tag #minecraft:logs represents all log blocks, so commands or recipes using that tag automatically apply to oak logs, birch logs, and any other block included in it. Tags are one of the most powerful data pack features for organizing and modifying game behavior without editing core files.

While some tags are only used in certain data pack files, others are used in hardcoded properties of a specifics features, where modifying such tags is the only way to include or exclude a certain property from a given features without mods.

Tags are part of the data pack directory structure, highlighted below:

Minecraft defines many tags in the vanilla data pack in the minecraft namespace. These tags are often referenced by the code or other vanilla data pack files. Modifying those tags through a data pack therefore has a direct effect. For example, vanilla block tags are used for various block behaviors, vanilla item tags are used for various item behaviors, vanilla advancement files and vanilla recipe files, and vanilla entity type tags are used for various mob behaviors. See § List of tag types section for their usages.

The resource location of a tag is also in the format of <namespace>:<path>, where namespace is the name of the folder that the tags folder is in, and path is the JSON file's path under the respective tag folder.

For example, JSON file 'data/wiki/tags/block/foo/example.json' defines a block tag with the resource location of wiki:foo/example.

To distinguish normal contents from tags, a # is usually required before tag's resource location.

{
 "replace": false,
 "values": [
 "minecraft:oak_log",
 "minecraft:birch_log",
 "minecraft:spruce_log"
 ]
}

This tag could be saved at data/example/tags/block/my_logs.json and used in commands or loot tables as #example:my_logs.

{
 "replace": false,
 "values": [
 "#minecraft:logs",
 "minecraft:cherry_log"
 ]
}

This adds cherry_log to the vanilla logs tag without overwriting its contents.

{
 "replace": true,
 "values": [
 "minecraft:diamond_block"
 ]
}

Setting replace to true completely overrides any lower-priority tags with the same name, replacing their contents entirely.

{
 "values": [
 { "id": "example:custom_item", "required": false }
 ]
}

Optional entries prevent load errors when a referenced object is missing (for example, in a different modded setup).

This section lists the tag types that are used by the game to affect its behavior in various ways, as well as those that are populated by default, even if the game does not use them to control some behavior.

It is possible to define tags for any registry and also functions. The list below show only the ones used by the game.

• Block
• Item
• Function
• Fluid
• Entity type
• Game event
• Biome
• Flat level generator preset
• World preset
• Structure
• Cat variant
• Point of interest type
• Painting variant
• Banner pattern
• Instrument
• Damage type
• Enchantment
• Dialog
• Timeline
• Potion
• Villager trade
• Configured feature​^{[until: JE 26.3]}
• Feature​^{[upcoming: JE 26.3]}

When multiple data packs define the same tag:

• The highest-priority pack (top of the list in the data packs screen) takes precedence.
• If its replace value is false, the tag’s contents are appended to lower-priority versions.
• If replace is true, the tag fully replaces all lower versions.

Because tags merge across data packs, they are commonly used by mods and servers to extend vanilla behavior without overwriting files. Many vanilla tags, such as #minecraft:planks or #minecraft:mineable/pickaxe, are referenced by block properties and determine what tools or interactions are valid.

When tags are merged across data packs, their values are appended at the end of the resulting in-memory tag, in the order that the data packs load.

When reading a tag, Minecraft follows the order of the values as written in the file, proceeding recursively for each sub-tag encountered. Since the vast majority of tags are used for simple boolean checks (whether a value is or is not in a tag), the order within a tag usually doesn't matter.

However, order does matter for:

• Patterns in the loom menu (#no_item_required).
• Enchantments in an item tooltip (#tooltip_order).
• Goat horn variants in the creative inventory (#goat_horns).
• Execution order of functions in a function tag.
• Recipe previews that show which items may be used in recipes that use tags.

Issues relating to "Tag" are maintained on the bug tracker. Issues should be reported and viewed there.

• Predicate – often references tags to match grouped items or blocks
• Loot table – uses tag conditions for item drops
• Data pack – framework where tags are defined

• Tag (Bedrock Edition)