The incompatibility groups
| Group | Enchantments | Why |
|---|---|---|
| Armor protection | Protection, Fire Protection, Blast Protection, Projectile Protection | All reduce incoming damage the same way; stacking two would double-count the same mitigation. |
| Sword damage | Sharpness, Smite, Bane of Arthropods | All modify the same melee damage roll for a different target type. |
| Mining vs collecting | Silk Touch, Fortune | Silk Touch replaces the drop entirely, which leaves nothing for Fortune to multiply. |
| Trident movement | Riptide, Loyalty, Channeling | Riptide propels the player on hit and cannot coexist with either enchantment that assumes the trident is thrown. |
| Crossbow projectiles | Multishot, Piercing | Both change how many entities a single bolt can affect, in incompatible ways. |
| Boots movement | Depth Strider, Frost Walker | Depth Strider speeds up swimming; Frost Walker prevents touching water at all. |
Outside these groups, vanilla enchantments freely combine — Unbreaking, Mending and Curse of Vanishing apply to almost any enchantable item and never conflict with anything.
Worked example: what actually happens if you force it
Try to combine Sharpness and Smite at an enchanting table, on an anvil, or with two enchanted books, and the interface simply will not let you — the second enchantment is greyed out or the anvil refuses the combination. That block lives in the crafting-side code, not in the item's data. Write both into an item directly, and the game does not stop you:
/give @p minecraft:diamond_sword[minecraft:enchantments={levels:{"minecraft:sharpness":5,"minecraft:smite":5}}] 1This item exists, both enchantments show in the tooltip, and both apply their damage bonus in combat. No survival player could ever obtain it through play, which is exactly why it reads as clearly out-of-the-ordinary the moment someone sees it — a useful signal for an admin-spawned relic, and a giveaway if you wanted the item to look legitimately player-made.
Where this shows up outside the enchanting table
The same groups matter in three other places creators run into:
- Anvil combining. Combining two books or an item and a book at an anvil rejects the second enchantment if it conflicts with one already on the target, the same way the enchanting table does.
- Loot tables. A
minecraft:set_enchantmentsfunction with a hand-written list does not check for conflicts — it is just data. A loot table can absolutely roll Sharpness and Smite on the same sword unless whoever wrote the table avoided it on purpose. - Command blocks and mob spawners. Any
/give,/item modify, or spawn-with-equipment setup has the same freedom and the same responsibility — the game will not warn you when a combination could never occur naturally.
Treasure enchantments
A handful of enchantments cannot appear from an enchanting table at all, at any level, no matter how much lapis or how many bookshelves surround it: Mending, Frost Walker, Curse of Binding, Curse of Vanishing, Soul Speed, Swift Sneak, and Channeling. These are "treasure" enchantments, obtainable only from fishing, trading, structure loot, or a /give command. A randomizer or loot table that rolls one onto a common item is deliberately generous — which is exactly the kind of thing worth doing on purpose rather than by accident.
Level caps are a suggestion, not a wall
Sharpness V is the highest an enchanting table or anvil combination will ever produce, but that cap belongs to the enchanting UI, not the enchantment itself. A /give command or a loot table's set_enchantments function can write any integer level into an item's data, and the game will happily apply Sharpness 100 to it. There is no clamp anywhere in item data — only the crafting-side systems that assign enchantments choose to stop at the vanilla cap.
What this means for a randomizer
A tool that rolls enchantments has three honest choices: stay inside vanilla's groups and level caps to produce something an in-game enchanting table could have made, allow treasure enchantments and call that out, or allow levels past the cap and call that out too. All three are legitimate depending on what you are building — a "realistic" loot table for a survival server wants the first, a boss-drop for an adventure map might want the third. The enchantment & attribute randomizer defaults to respecting the groups, with an explicit checkbox to turn that off.
FAQ
Can two treasure enchantments ever conflict with each other?
Yes — being "treasure only" and belonging to an incompatibility group are separate rules. Frost Walker and Channeling are both treasure enchantments, but Frost Walker still conflicts with Depth Strider and Channeling still conflicts with Riptide, exactly as if they were common enchantments.
Does Bedrock Edition use the same groups?
The groups themselves are the same short list; this page and the randomizer are written and tested against Java Edition syntax, which is what most data pack and command-block workflows target.
Will a data pack ever let me override these groups legitimately?
Custom enchantments defined through the data-driven enchantment system can declare their own exclusive sets, separate from vanilla's. That is a data pack authoring topic on its own, outside what a vanilla-focused randomizer covers.
Why does the randomizer default to respecting the groups instead of ignoring them?
Because the more common request is "give me something a player could plausibly have found," and that only holds if the groups are respected. Generosity past that point should be a choice, not an accident.
Where to go next
Ready to roll a set: the randomizer and its usage guide cover the basic/advanced modes and the two output formats. For enchantments alongside a fully custom item definition rather than a vanilla one, see the custom item catalog.