Minecraft Bedrock Custom Recipes Guide (2026)

The short answer

Every custom Bedrock recipe is a separate JSON file inside the Behavior Pack recipes/ folder. Choose the recipe type, give it a unique namespaced identifier, select the crafting-station tags, define valid inputs, and point the result to an item that already exists.

MyAddon_BP/
  manifest.json
  items/
    copper_hammer.json
  recipes/
    copper_hammer.json
    ruby_apple_upgrade.json
    smelt_raw_ruby.json

Recipes do not belong in the Resource Pack. The Resource Pack may provide the icons and names for custom ingredients or outputs, but the recipe itself is Behavior Pack data.

Choose the right recipe type

• Shaped: use this when the arrangement communicates the object, such as tools, armor, machines, or decorative patterns.
• Shapeless: use this for mixing, recoloring, conversion, recycling, or upgrades where slot positions do not matter.
• Furnace: use this for smelting or cooking in one or more supported stations.
• Brewing: use this for potion input, reagent, and potion output combinations.
• Smithing transform or trim: use this only when the inputs match the restrictions of the smithing interface.

Do not force every recipe into the crafting table. The station is part of the player's understanding of progression.

Shaped recipe example

This recipe creates icedfox:copper_hammer. Each non-space character in the pattern must have a matching entry in key. Spaces represent empty slots.

{
  "format_version": "1.20.10",
  "minecraft:recipe_shaped": {
    "description": {
      "identifier": "icedfox:recipe_copper_hammer"
    },
    "tags": ["crafting_table"],
    "pattern": [
      "CCC",
      " S ",
      " S "
    ],
    "key": {
      "C": {
        "item": "minecraft:copper_ingot"
      },
      "S": {
        "item": "minecraft:stick"
      }
    },
    "result": {
      "item": "icedfox:copper_hammer",
      "count": 1
    }
  }
}

Pattern rules that cause most mistakes

• Every row should use a consistent width for the intended grid.
• A key is one character. Do not use words such as INGOT in the pattern.
• Every pattern character must exist in key.
• The output identifier must refer to a registered item.
• The recipe identifier must be unique, even if two recipes produce the same output.

Shapeless recipe example

A shapeless recipe uses an ingredients array instead of pattern and key. Here, a Ruby Apple and glow berries produce a Glowing Ruby Apple in any arrangement.

{
  "format_version": "1.20.10",
  "minecraft:recipe_shapeless": {
    "description": {
      "identifier": "icedfox:recipe_glowing_ruby_apple"
    },
    "tags": ["crafting_table"],
    "ingredients": [
      {
        "item": "icedfox:ruby_apple"
      },
      {
        "item": "minecraft:glow_berries"
      }
    ],
    "result": {
      "item": "icedfox:glowing_ruby_apple",
      "count": 1
    }
  }
}

Use a shaped recipe if players should remember a silhouette. Use shapeless when the recipe represents combining ingredients rather than constructing a shape.

Furnace and cooking recipes

A furnace recipe uses string identifiers for input and output. The tags array decides which stations accept it.

{
  "format_version": "1.12",
  "minecraft:recipe_furnace": {
    "description": {
      "identifier": "icedfox:smelt_raw_ruby"
    },
    "tags": ["furnace", "blast_furnace"],
    "input": "icedfox:raw_ruby",
    "output": "icedfox:ruby"
  }
}

Use only the stations that make sense. Food might use furnace, smoker, and campfire; ore processing might use furnace and blast_furnace. Do not add every tag merely to make testing easier.

Use item tags without making recipes fragile

Recipe inputs can accept item tags, which lets one recipe work with a family of ingredients such as planks. This is better than duplicating the same file for every wood type.

"P": {
  "tag": "minecraft:planks"
}

Start with exact item IDs while debugging. Once the recipe works, replace the intended ingredient with a documented tag and test several matching items. A misspelled tag can make a valid-looking recipe impossible to craft.

A reliable recipe test

1. Confirm every custom input and output works with /give.
2. Enable the Content Log before opening the test world.
3. Start with one recipe file and exact item identifiers.
4. Use a fresh crafting table or station after reloading.
5. Place the exact ingredient counts and positions shown in the JSON.
6. Test in Survival as well as Creative.
7. Add tags or alternate stations only after the basic recipe succeeds.

This order proves the item layer before the recipe layer. Otherwise, a missing output item can look like a broken recipe even when the recipe JSON is valid.

Why a custom recipe does not work

The recipe file is ignored

Verify it is under the active Behavior Pack recipes/ folder, has a .json extension, and contains valid JSON. Check the first Content Log error rather than the final cascade of errors.

The pattern looks correct but never matches

Check spaces, row widths, key characters, and item identifiers. Copying typography from formatted websites can insert smart quotes or invisible characters into JSON.

The recipe crafts the wrong output or conflicts

Give each recipe a unique namespaced identifier. Use priority only when you have a real matching conflict and understand which recipe should win.

A tag accepts nothing

Replace the tag with one exact item ID. If that works, the station and recipe structure are valid; the tag name or the tags on your custom items are the remaining suspects.

The recipe works in one world but not another

Compare the active pack versions and dependencies. Imported duplicates and stale world packs are common, especially when development and release copies share UUIDs but have inconsistent versions.

Design recipes for players, not only for JSON

Technical validity is only the first pass. A useful recipe should also communicate value and progression:

• Match ingredient cost to the power and durability of the output.
• Reuse visual patterns for tool families so players can infer new recipes.
• Avoid ingredients that are unavailable at the point where the item is needed.
• Document unusual stations or multi-stage crafting inside the addon wiki.
• Test recipe overlap with other addons and vanilla recipe patterns.

If a recipe needs a paragraph to explain its arbitrary arrangement, the pattern probably needs another design pass.

Frequently asked questions

Can one output have multiple recipes?

Yes. Each recipe needs its own unique identifier. This is useful for alternate materials, recycling, or progression variants.

Can custom items be used as ingredients?

Yes. Reference the full namespaced item identifier, such as icedfox:ruby_apple. Confirm the item exists before debugging the recipe.

Can a custom recipe use any kind of wood?

Use the documented minecraft:planks tag as the ingredient. Test the exact current behavior with multiple wood types before release.

Do I need Script API for custom recipes?

No. Standard shaped, shapeless, furnace, brewing, and smithing recipes are data-driven JSON. Use scripts only for mechanics the recipe system cannot represent.

Official sources checked

• Microsoft Learn: Recipe JSON Documentation
• Microsoft Learn: Shaped Recipe
• Microsoft Learn: Shapeless Recipe
• Microsoft Learn: Furnace Recipe
• Microsoft Learn: Tags as Recipe Input

Continue building

• Make a Custom Item in Minecraft Bedrock
• Bedrock manifest.json Guide
• Bedrock Addon Debugging Checklist
• Fix Addon Items That Do Not Work