Short answer: most things match, a few get replaced

When blocks or coordinates feel “off” after a conversion, it’s usually not a bug—it’s that Java Edition and Bedrock genuinely differ on a few blocks and coordinate-system details. The TopoBlocks conversion is one-way Java Edition → Bedrock, and it maps blocks along the way: the vast majority of blocks map one-to-one, and only a handful of Java-only blocks—which Bedrock has no exact counterpart for—get replaced with the closest compatible equivalent. We never promise “100% lossless,” but we also never swap things silently—every change is written into the itemized change report you get when it finishes. To understand the underlying differences between the two editions first, see What’s the difference between Java Edition and Bedrock.

Which “mismatches” are normal

  • A few Java-only blocks get replaced. When Bedrock has no exact equivalent, the conversion picks the closest compatible equivalent rather than dropping the block. The report lists each original block and its replacement, line by line.
  • Differences in block orientation, waterlogged state, and similar details. The two editions represent some block states differently, so there can be minor discrepancies after migration—that’s an edition difference, not a coordinate mix-up.
  • Visual differences at chunk boundaries. World data is stored per chunk, and the two editions don’t handle chunk boundaries identically, so from a distance a spot may look “a little different.”

It’s worth stressing: terrain and structure layout are normally migrated at their original coordinates, with no overall shift or misalignment. For a more complete picture of “what transfers and what doesn’t,” see Java to Bedrock: what transfers and what doesn’t.

How to verify before and after conversion

So you can “see clearly before deciding,” the conversion flow is deliberately split into two steps:

  1. Check the compatibility score before paying—it estimates how much of this map will migrate fully and how much may be replaced, so you can judge whether it’s worth converting.
  2. Read the itemized report when it finishes—it lists every block replaced with a compatible equivalent, plus anything noted in the report, so you can cross-check after importing into Bedrock and know exactly what to expect.

Conversion is pay-per-use, failures are auto-refunded, and prices are shown in the app; and it never overwrites your source file—each run generates a new .mcworld, your original Java world (hash and all) is preserved and traceable, and you can start over if you’re not satisfied. For compatibility of the output across different versions (such as 1.20/1.21), see Is the converted world version-compatible (1.20/1.21). For the full conversion steps, see the in-depth tutorial Java to Bedrock.