Minecraft Bedrock Loot Tables Guide (2026)

Control what mobs, containers, and gameplay systems produce with weighted entries, conditions, count functions, custom items, and tests you can trust.

Stable Bedrock workflowThis guide was checked against the stable Minecraft Creator documentation in July 2026. The examples use Behavior Pack loot tables and current namespaced item identifiers.

The short answer

A Minecraft Bedrock loot table is a JSON file in a Behavior Pack. It contains one or more pools; each pool makes a number of rolls and selects entries according to their weights. Conditions decide whether a pool or entry is eligible, while functions change the selected item, count, enchantments, or other properties.

For a custom mob, create the table under loot_tables/entities/ and point the entity's minecraft:loot component to it. Start with one guaranteed vanilla item. Once that works, add custom items, weights, conditions, and functions one layer at a time.

Use a predictable file structure

Behavior Pack structure
ForestGuardian_BP/
  manifest.json
  entities/
    forest_guardian.json
  items/
    ancient_seed.json
  loot_tables/
    entities/
      forest_guardian.json
    chests/
      forest_cache.json

The path used in an entity or command starts at the Behavior Pack root. In this example the entity table is loot_tables/entities/forest_guardian.json. Letter case, underscores, and the .json extension must match the real file.

Build one guaranteed drop first

Create loot_tables/entities/forest_guardian.json with a single pool and a single item. This deliberately boring version proves the table can be found and parsed.

loot_tables/entities/forest_guardian.json
{
  "pools": [
    {
      "rolls": 1,
      "entries": [
        {
          "type": "item",
          "name": "minecraft:emerald"
        }
      ]
    }
  ]
}

Then reference the table from the custom entity's Behavior Pack definition:

entities/forest_guardian.json excerpt
"components": {
  "minecraft:health": {
    "value": 40,
    "max": 40
  },
  "minecraft:loot": {
    "table": "loot_tables/entities/forest_guardian.json"
  }
}

Kill the entity in a clean test world. If the emerald appears, the file path and entity connection are working. If it does not, do not add rarity logic yet; open the Content Log and fix the foundation.

Add weighted drops and a no-drop chance

Weights are relative, not percentages. With weights 6, 3, and 1, the eligible entries have 60%, 30%, and 10% of the total weight. An empty entry is the clearest way to make a roll produce nothing.

Weighted rare drop pool
{
  "pools": [
    {
      "rolls": 1,
      "entries": [
        {
          "type": "empty",
          "weight": 6
        },
        {
          "type": "item",
          "name": "minecraft:emerald",
          "weight": 3
        },
        {
          "type": "item",
          "name": "icedfox:ancient_seed",
          "weight": 1
        }
      ]
    }
  ]
}

This pool has a 60% no-drop chance, a 30% emerald chance, and a 10% custom seed chance. The custom item must already be valid and load from an active Behavior Pack. Follow the custom Bedrock item guide before blaming the loot table for an unknown identifier.

Keep separate ideas in separate poolsUse one pool for a guaranteed base drop and another for an independent rare drop. Putting everything in one pool means only the selected entry for that roll wins.

Control item counts with functions

The set_count function can assign a fixed value or a random range. The looting_enchant function can then increase the result when the kill qualifies for Looting.

Count and Looting example
{
  "type": "item",
  "name": "minecraft:string",
  "weight": 1,
  "functions": [
    {
      "function": "set_count",
      "count": {
        "min": 1,
        "max": 3
      }
    },
    {
      "function": "looting_enchant",
      "count": {
        "min": 0,
        "max": 1
      }
    }
  ]
}

Test the normal kill and the Looting kill separately. Random systems need repeated trials; ten kills can expose a path or syntax failure, while a larger sample is needed to judge whether your intended rarity feels right.

Use conditions without hiding every drop

Conditions can sit on a pool, an entry, or some functions. A killed_by_player condition is useful when farms or environmental damage should not produce a special reward.

Player-only rare item
{
  "rolls": 1,
  "entries": [
    {
      "type": "item",
      "name": "icedfox:ancient_seed",
      "weight": 1
    }
  ],
  "conditions": [
    {
      "condition": "killed_by_player"
    }
  ]
}

Place the condition only around the reward it should govern. A condition on the entire table or the wrong pool can accidentally suppress ordinary drops too.

Complete custom mob loot table

This version always rolls for basic materials and independently rolls for the player-only rare seed.

Complete forest guardian table
{
  "pools": [
    {
      "rolls": 1,
      "entries": [
        {
          "type": "item",
          "name": "minecraft:stick",
          "weight": 3,
          "functions": [
            {
              "function": "set_count",
              "count": { "min": 1, "max": 3 }
            }
          ]
        },
        {
          "type": "item",
          "name": "minecraft:emerald",
          "weight": 1
        }
      ]
    },
    {
      "rolls": 1,
      "entries": [
        { "type": "empty", "weight": 9 },
        {
          "type": "item",
          "name": "icedfox:ancient_seed",
          "weight": 1
        }
      ],
      "conditions": [
        { "condition": "killed_by_player" }
      ]
    }
  ]
}

A reliable loot table test

  1. Confirm the entity loads before adding minecraft:loot.
  2. Use a table with one guaranteed vanilla item.
  3. Kill the entity and inspect the Content Log.
  4. Replace the vanilla item with your custom identifier.
  5. Add counts, then weights, then conditions.
  6. Test player kills, environmental kills, and Looting separately.
  7. Repeat enough trials to distinguish rarity from a broken table.

Also test with only one imported copy of the pack. Duplicate versions can make you edit one folder while the world loads another. The Bedrock add-on debugging checklist covers that cache problem in detail.

Why a Bedrock loot table does not work

The mob drops nothing

Verify the minecraft:loot component, exact relative table path, JSON syntax, active Behavior Pack, and Content Log. Temporarily reduce the table to one guaranteed diamond or emerald.

Vanilla items drop but custom items do not

The table is loading. Check the custom item's complete namespaced identifier and confirm its item JSON loads without errors.

The rare item never appears

Replace the empty entry temporarily, set the rare entry's weight to the only eligible weight, and remove conditions. Reintroduce each rule after the item appears.

Every drop appears at once

Each pool rolls independently. If you want one winner from several options, keep those options in the same pool. If you want several independent rewards, split them across pools.

Looting changes nothing

Confirm the looting_enchant function is attached to the item entry, test with a real Looting weapon, and compare enough kills for the random difference to become visible.

Frequently asked questions

Can loot tables fill chests?

Yes. Loot tables are used for entities, containers, blocks, gameplay systems, and commands. Keep chest tables under a clear folder such as loot_tables/chests/ and test the exact system that calls them.

Can one loot table reference another?

Yes. An entry can use the type loot_table and point to a shared table. This is useful for reusable reward pools, but do not create direct or indirect recursive references.

Do weights have to total 100?

No. Minecraft compares relative weights. Values 6, 3, and 1 behave like 60%, 30%, and 10%, while 60, 30, and 10 produce the same ratio.

Official sources checked