Java vs. Bedrock Anvil Cost Differences

Java and Bedrock don't just have different enchantment tables and villager trades — their anvils genuinely compute cost differently. This isn't a rumor or a rounding difference; it's a real divergence in the formula itself, confirmed against both editions' source rules in AnvilCalc's own calculation engine.

The one real formula difference

Both editions price an anvil operation by looking at each enchantment being merged and multiplying a level count by that enchantment's rarity multiplier. The divergence is in which level count:

• Java charges for the enchantment's final level. Whatever level the enchantment ends up at on the resulting item, that's what you pay for — multiplied by its rarity multiplier — regardless of what level it started at.
• Bedrock charges only for the level increase. It takes the final level, subtracts the level the target already had, and multiplies that difference by the rarity multiplier. If the level didn't go up, you pay nothing for that enchantment.

The Sharpness I → III worked example

This is the clearest way to see it. Say you have a sword already enchanted with Sharpness III, and you sacrifice a book with only Sharpness I on it — a merge that does nothing to the sword's Sharpness level, since III is already higher than I.

• In Java: cost = final level × multiplier = 3 × 1 = 3 levels. You pay for Sharpness III existing on the result, even though the sacrifice didn't raise anything.
• In Bedrock: cost = (final level − initial level) × multiplier = (3 − 3) × 1 = 0 levels. Since the sword's Sharpness level didn't actually increase, Bedrock charges nothing for it.

Same sword, same book, same merge — 3 levels in Java, free in Bedrock. That's the whole divergence in one example, and it's why a sequence of combines that looks perfectly reasonable on a Bedrock world can run noticeably more expensive if you plan it the same way on Java.

The other difference: the incompatible-enchantment penalty

Java and Bedrock also handle a dropped enchantment differently. If your sacrifice carries an enchantment that conflicts with something already on the target — say a Smite book merged onto a Sharpness sword — that conflicting enchantment is simply dropped in both editions (neither edition blocks the merge outright over a conflict). But Java additionally tacks on a flat +1 level penalty for every enchantment it drops this way; Bedrock adds nothing extra for the same dropped enchantment. It's a smaller effect than the final-level-vs-increase difference, but it compounds with it over a multi-step combine plan.

Why this matters for planning a build

Both differences point the same direction: Java is consistently the pricier edition for the exact same sequence of combines, because it charges for results (final levels, dropped enchantments) rather than changes (level increases only, no conflict fee). If you're planning a combine order by hand, assuming Bedrock's cheaper numbers apply to Java will under-budget your levels — and the gap gets larger the more steps and the more conflicting enchantments are involved. The 39-level "Too Expensive!" cap (see Anvil Too Expensive) applies identically to both editions per step, so a plan that's comfortably under the cap on Bedrock can land right at — or past — that ceiling on Java for the identical build.

This is exactly why AnvilCalc asks which edition you're playing before it searches for a combine order: the same target item and enchantment list can have a different cheapest path, and a different total cost, purely because of which formula applies. See Enchanting Strategy for the prior-work penalty that applies identically to both editions on top of this.

Open the calculator →

Frequently asked questions

Is enchanting cheaper on Bedrock than Java?

For anvil combining specifically, yes, in most realistic cases. Bedrock only charges for the level increase an enchantment actually gains, while Java charges for its full final level regardless of the starting point. Java also adds a flat +1 level penalty for every incompatible enchantment dropped during a merge, which Bedrock does not.

Why does sacrificing Sharpness I onto a Sharpness III item cost anything in Java?

Because Java prices the enchantment's final level on the result, not the increase. The sword ends the merge with Sharpness III either way, so Java charges 3 × the rarity multiplier even though the sacrifice's own level (I) was lower than what the sword already had.

Does Bedrock have the same 39-level "Too Expensive!" cap as Java?

Yes — the cap is the same 39 levels per operation on both editions. The difference is entirely in how each edition calculates the cost that gets compared against that cap, not in the cap itself.

Does a conflicting enchantment block an anvil merge in either edition?

No, in neither edition. A conflicting enchantment on your sacrifice is simply dropped rather than applied; the merge still goes through. Java adds a flat +1 level fee per dropped enchantment on top of that, while Bedrock charges nothing extra for it.

Why does AnvilCalc ask which edition I'm playing before calculating a plan?

Because the cost formula itself is different, not just the available enchantments or versions. The same item, the same target enchantments, and even the same combine order can come out at a different total XP cost — and sometimes a different cheapest order entirely — depending on whether Java's final-level formula or Bedrock's level-increase formula applies.