Loot table

Loot tables are technical JSON files that are used to dictate what items should generate in various situations, such as what items should be in naturally generated containers, what items should drop when breaking a block or killing a mob, what items can be fished, and more. They do not affect dropped experience, or dropped non-item entities such as slimes from larger slimes or silverfish from infested blocks.

Definition[]

Custom data packs use loot tables to change what loot can spawn in containers or drop by mobs. They can either change existing loot tables or create new ones. Note that some blocks, such as bedrock, end portals and other blocks unbreakable in Survival do not have loot tables, some blocks share loot tables (namely wall and floor variants of blocks) and that certain drops, namely head drops from charged creepers and the wither's nether star, are currently not covered by loot tables.^[1]

Loot tables belong in the following folder of a data pack's structure:

(data pack name)
- data
  - (namespace)
    - loot_tables (pre-1.21)
    - loot_table (1.21+)
      - (loot_table_name).json

Vanilla loot tables are grouped into 4 categories: gameplay (fishing, cat morning gift, piglin bartering), entities, blocks, and chests, with some tables being in subfolders of those. For example, the file for zombies would go in data pack name/data/minecraft/loot_tables/entities/zombie.json. This makes every zombie in that world use the datapack's loot table rather than the default zombie loot table.

Usage[]

The loot tables are structured as a String tag that determines the table to use, and a Long tag determining the seed. Containers or mobs with the same seed and table drop the same items. Loot tables do not determine the container's slot to be used; that is randomly determined based on the seed.

For barrel, chest, trapped chest, hopper, minecart with chest, boat with chest, minecart with hopper, dispenser, dropper, and shulker box:

The root object.
- LootTable: Loot table to be used to fill the container when it is next opened, or the items are otherwise interacted with. When the container is a chest that is part of a double chest, only the half corresponding to the tagged single-chest is affected.
- LootTableSeed: Seed for generating the loot table. Works similarly to the seeds for worlds. 0 or omitted uses a random seed.

These tags are removed once the items have been interacted with (by opening the container, breaking the container, etc.), and only then are items put in the container.

For mobs:

The root object.
- DeathLootTable: Loot table to be used for the items that drop when the entity is killed.
- DeathLootTableSeed: Seed for generating the loot table. Works similarly to the seeds for worlds. 0 or omitted uses a random seed.

The loot tables of mobs and containers can be altered with /execute store and /data. The player could also grant a loot table to an entity or drop it in the world with /loot.

Tags[]

Loot tables are defined using the JSON format. Below are a list of tags used.

The root object.
- type: Optional, specifies the context in which the loot table should be invoked. All item functions, predicates and number providers are then validated to ensure the parameters of the context type specified here will cover all requirements, and prints a warning message in the output log if any function or condition requires a context parameter that is not covered. Valid loot context types are described below.
- functions: Invokes item functions, in order, upon all item stacks generated by this table.
  - An item function. The JSON structure of this object is described on the Item modifiers page.
- pools: A list of all pools for this loot table. Each pool used generates items from its list of items based on the number of rolls. Pools are applied in order.
  - A pool. The JSON structure of this object is described below.
- random_sequence: A resource location specifying the name of the random sequence that will be used to generate loot from this loot table. If only one loot table uses a specific random sequence, the order of the randomized sets of items generated is the same for every world using the same world seed. If multiple loot tables use the same random sequence, the loot generated from any one of them changes depending on how many times and in what order any of the other loot tables were invoked.

Pool[]

The root object.
- conditions: A list of predicates that must all pass for this pool to be used.
  - A predicate. The JSON structure of this object is described on the Predicates page.
- functions: Invokes item functions, in order, to all item stacks generated by this pool.
  - An item function. The JSON structure of this object is described on the Item modifiers page.
- rolls: A Number Provider. Specifies the number of rolls on the pool.
- bonus_rolls: A Number Provider. Specifies the number of bonus rolls on the pool per point of luck. Rounded down after multiplying. Defaults to exactly 0.0.
- entries: A list of all things that provide loot entries for this pool. One loot entry is chosen per roll as a weighted random selection from all loot entries added into the pool. Note that it is not selected weightedly from the elements of this list, instead, the weighted selection is to select from all loot entries provided by these elements (entry providers), which are different because an element (entry provider) can provide empty, or one or more weighted loot entries.
  - The JSON structure of this object is described below.

Entry provider[]

The root object.
- conditions: A list of predicates that must all pass for the provided loot entry/ies to be added into the loot pool.
  - A predicate. The JSON structure of this object is described on the Predicates page.
- type: Resource location of the type of entry provider. Set to one of the following values.

The possible values for type and associated extra contents:

item—Provides a loot entry that drops a single item stack.
- functions: Invokes item functions to the item stack(s).
  - An item function. The JSON structure of this object is described on the Item modifiers page.
- weight: Determines how often the loot entry is chosen out of all the entries in the pool. Entries with higher weights are used more often. The chance of an entry being chosen is [this entry's weight ÷ total of all considered entries' weights].
- quality: Modifies the loot entry's weight based on the luck attribute of the killer_entity for loot context type entity or the this entity for all other loot table types. Formula is floor(weight + (quality × generic.luck)).
- name: The resource location of the item to be generated, e.g. minecraft:diamond. The default, if not changed by item functions, is a stack of 1 of the default instance of the item.

tag—Provides a loot entry that generates all item in an item tag, or multiple loot entries (each entry generates a single item in the item tag).
- functions: Invokes item functions to the item stack(s).
  - An item function. The JSON structure of this object is described on the Item modifiers page.
- weight: Determines how often a loot entry is chosen out of all the entries in the pool. Entries with higher weights are used more often. The chance of an entry being chosen is [this entry's weight ÷ total of all considered entries' weights].
- quality: Modifies the loot entry's weight based on the luck attribute of the killer_entity for loot context type entity or the this entity for all other loot table types. Formula is floor(weight + (quality × generic.luck)).
- name: The resource location of the item tag to query, e.g. minecraft:arrows.
- expand: If set to true, provides one loot entry per item in the tag with the same weight and quality, and each entry generates one item. If false, provides a single loot entry that generates all items (each with count of 1) in the tag.

loot_table—Provides another loot table as a loot entry.
- functions: Invokes item functions to the item stack(s).
  - An item function. The JSON structure of this object is described on the Item modifiers page.
- weight: Determines how often the loot entry is chosen out of all the entries in the pool. Entries with higher weights are used more often. The chance of an entry being chosen is [this entry's weight ÷ total of all considered entries' weights].
- quality: Modifies the loot entry's weight based on the luck attribute of the killer_entity for loot context type entity or the this entity for all other loot table types. Formula is floor(weight + (quality × generic.luck)).
- name: The resource location of the loot table to be used, e.g. minecraft:gameplay/fishing/junk.

dynamic—Provides a loot entry that generates block-specific drops.
- functions: Invokes item functions to the item stack(s).
  - An item function. The JSON structure of this object is described on the Item modifiers page.
- weight: Determines how often the loot entry is chosen out of all the entries in the pool. Entries with higher weights are used more often. The chance of an entry being chosen is [this entry's weight ÷ total of all considered entries' weights].
- quality: Modifies the loot entry's weight based on the luck attribute of the killer_entity for loot context type entity or the this entity for all other loot table types. Formula is floor(weight + (quality × generic.luck)).
- name: Can be contents to drop block entity contents.

empty—Provides a loot entry that generates nothing into the loot pool.
- functions: Invokes item functions to the item stack(s).
  - An item function. The JSON structure of this object is described on the Item modifiers page.
- weight: Determines how often the loot entry is chosen out of all the entries in the pool. Entries with higher weights are used more often. The chance of an entry being chosen is [this entry's weight ÷ total of all considered entries' weights].
- quality: Modifies the loot entry's weight based on the luck attribute of the killer_entity for loot context type entity or the this entity for all other loot table types. Formula is floor(weight + (quality × generic.luck)).

group—All entry providers in the children list is applied into the loot pool. Can be used for convenience, e.g. if one condition applies for multiple entries.
- children: The list of entry providers.
  - An entry provider.

alternatives—Only the first successful (conditions are met) entry provider, in order, is applied to the loot pool.
- children: The list of entry providers.
  - An entry provider.

sequence—The child entry providers are applied to the loot pool in sequential order, continuing until an entry provider's conditions are not met, then applying no more entry providers from the children.
- children: The list of entry providers.
  - An entry provider.

Recurring JSON structures within loot tables and other data pack files[]

Predicate[]

Predicates (aka. Loot conditions) are JSON structures that are used within loot tables to add requirements to a drop, pool, or function. They can also be used in standalone files (see Predicate), where they can be called upon from multiple different contexts.

The specific structure of a predicate is shown on the Predicates page.

Item function[]

Item functions (aka. loot functions) are used within loot tables to apply modifications to the item stack being generated, such as adjusting the stack size or adding enchantments. They can also be used in standalone files called Item modifiers, where they can be called upon to modify items in an already existing item slot within a block or entity's inventory.

The specific structure of an item function is shown on the Item modifiers page.

Number Providers[]

Loot tables use number providers in some places that accept an int or float. They can either be defined as a constant value or as an object.

: Constant number provider.

Or:

: The root tag.
- type: The number provider type.

The possible values for type and associated extra contents:

constant—A constant value.
- value: The exact value.

uniform—A random number following a uniform distribution between two values (inclusive).
- min: Number provider. The minimum value.
- max: Number provider. The maximum value.

binomial—A random number following a binomial distribution
- n: Number provider. The amount of trials.
- p: Number provider. The probability of success on an individual trial.

score—To query and use a scoreboard value.
- target: To choose which player name or entity UUID to query.
  - type: Set to fixed to manually specify a player name or UUID. Set to context to use an entity from loot context.
  - name: Included only if type is set to fixed. Specifies the name of the player, or the entity's UUID (in hypenated hexadecimal format) whose score to query.
  - target: Included only if type is set to context. Specifies an entity from loot context to query the score of. Can be this, killer, direct_killer, or killer_player.
- score: The scoreboard objective to query on the selected player name or UUID.
- scale: Optional. Scale to multiply the score before returning it.

Loot context types[]

The type field is used when loading the data pack to check whether the context parameters used by this loot table match the specified context type. The field makes it possible to check for errors in the loot table files without applying them in-game. If the loot table is used for a specific context, specifying the type field allows the game to check whether the loot table file uses parameters that will not be provided in that context.

Depending on the type of invocation, different parameters may be supplied to predicates, loot functions and number providers. Below is a list of all possible contexts of invocation, and the parameters:

Loot context type	When it is used	Loot context parameters that are supplied	Loot context parameters that may be supplied
`empty`	Only used by the hardcoded empty loot table. Supplies no loot context parameters. Specifying `"type":"empty"` means no context parameters can be used in this loot table.	None	None
`chest`	Opening of a container with loot table (can be barrel, chest, trapped chest, hopper, minecart with chest, boat with chest, minecart with hopper, dispenser, dropper, and shulker box). The command `/loot … loot <loot_table>`.	Origin: The center of the chest.	`this` entity: The entity that opened the chest.
`command`	Not used for loot tables. Specifying `"type":"command"` doesn't make sense. Used internally by commands such as `/item modify` or `/execute (if\|unless) predicate`.	Origin: The position where the command is run.	`this` entity: The entity that is `@s` when the command is run.
`selector`	Not used for loot tables. Specifying `"type":"selector"` doesn't make sense. Used internally by the `predicate` target selector argument.	Origin: The position of the entity being checked. `this` entity: The entity being checked.
`fishing`	Fishing. The command `/loot … fish <loot_table>`.	Origin: The position of the fishing bobber. Tool: The fishing rod item that the player cast	`this` entity: The fishing bobber.
`entity`	Loot from a living entity's death. The command `/loot … kill <target>`.	`this` entity: The entity that died. Origin: The location of the entity's death. Damage source: The source of the damage that caused the entity to die.	`killer` entity: The entity that was the source of the final damage to the victim entity. `direct_killer` entity: The entity that directly contacted the victim entity to kill them. `killer_player` entity: The player that most recently damaged the victim entity.
`archaeology`	Using a brush on suspicious sand that has a loot table.	Origin: The center of the suspicious sand.	`this` entity: The entity that used the brush on the suspicious sand.
`gift`	Gift from a cat or villager.	Origin: The cat or villager's location. `this` entity: The cat or villager that gave the gift.
`barter`	Bartering with piglins.	`this` entity: The piglin bartered with.
`advancement_reward`	Loot table set as an advancement's reward.	`this` entity: The player that gained the advancement. Origin: The player's location when they gained the advancement.
`advancement_entity`	Not used for loot tables. Specifying `"type":"advancement_entity"` doesn't make sense. Used internally when an advancement invokes a predicate on an entity.	`this` entity: The entity being checked. Origin: The position of the player who triggers this advancement criterion.
`advancement_location`	Not used for loot tables. Specifying `"type":"advancement_location"` doesn't make sense. Used internally when an advancement invokes a predicate on the location of a block which an item was used on.	`this` entity: The player to gain the advancement. Origin: The center of the block that was interacted with. Tool: The item used to interact with the block. Block state: The block that was interacted with.
`generic`	Not used. Supplies all loot context parameters. Specifying `"type":"generic"` or omitting it means no checking for context parameters in this loot table when loading the data pack.	N/A	N/A
`block`	Loots from breaking a block. The command `/loot … mine <pos>`.	Block state: The block that was broken. Origin: The center of the broken block. Tool: The tool used to mine the block.	`this` entity: The player that mined the block. Block entity: Any block entity data of the block that was broken, if it was a block entity. Explosion radius: The radius of the explosion that broke the block, if broken via an explosion.

History[]

Java Edition
1.9	October 19, 2015	Dinnerbone announces loot tables.
	15w43a	Added loot tables.
	15w43b	Added condition entity_scores.
	15w43c	Renamed "villager_golem.json" to "iron_golem.json"
		Added fishing loot tables, sheep without wool, and zombie and skeleton horses.
		Renamed the tag item: to name:, and the tag items: to entries:
		Added the tag type: and support to load a loot table instead of an item.
		Added the tag luck: to default files, though it currently does nothing in the code.
		Added the function set_damage.
	15w44a	Added the function enchant_randomly and set_attributes.
	15w44b	Added the quality tag.
		Removed luck and luck_multiplier tags.
		Added the bonus_rolls tag.
	15w51a	A player in Spectator mode no longer triggers a container to use its loot table to generate loot.
1.9.1	pre1	Loot tables now work with dispensers and droppers.
1.9.1	pre1	Added default table `chests/jungle_temple_dispenser`.
1.11	16w32a	Donkeys, mules, husks and zombie villagers now each draw from their own loot tables, rather than drawing from the horse and zombie loot tables, respectively
1.11	16w43a	Villagers, vexes and ender dragons are now able to draw from their own loot tables.
1.13	17w43a	Custom loot tables have been moved into data packs.
1.14	18w43a	Block drops have been changed to use loot tables.
		Loot tables received several new options.
		Setting entity to "this" now refers to the player in chest and block loot tables.
	18w44a	Added loot tables for cats, cat_morning_gift, players and withers.
		Added loot tables for new blocks.
		Added the function set_lore.
	18w46a	Added loot table for illusioners.
	18w48a	Added more loot tables for villages, some of which are currently unused.
	18w48a	Removed loot table: village_blacksmith.
	18w49a	village_savanna_house and village_snowy_house loot tables are now used.
	18w49a	Added more loot tables for villages.
	18w50a	village_desert_house and village_taiga_house loot tables are now used, making all previously unused loot tables no longer unused.
	?	Empty loot table is now hardcoded.
1.15	19w34a	Added the function copy_state.
1.16	20w12a	Added fishing_hook sub-predicate to check properties of the fishing hook.
1.20	23w14a	Added the function `reference`.
	23w17a	Added the loot table `sniffer_digging`.
	pre1	Made random sequences for loot tables deterministic.
	pre1	Added `random_sequence` field.
	pre6	The ID of the random sequence is now an optional field.
Upcoming Java Edition
1.20.2	23w32a	Added `sequence` loot function.
1.20.2	23w32a	`all_of` predicates in loot tables can now be declared implicitly as an inline array without a type.

Issues[]

Issues relating to "Loot table" are maintained on the bug tracker. Report issues there.

References[]

↑ MC-94610

[1] MC-94610

[1]