Files are converted in your browser and never uploaded.
On Windows, a structure block in Load mode imports the .mcstructure. On other devices, use the pack.
Java and Bedrock name most blocks and their states differently. A Java oak stair facing east is a Bedrock oak stair with weirdo_direction 0, a log's axis is Bedrock's pillar_axis, and a waterlogged slab is a plain slab with water in a second block layer. The converter translates every state through a table of all of Java's block states and what Bedrock calls each one.
To test it, all 1,511 structures that ship with Java 26.3 were converted to Bedrock and back, and 99.75% of 1.17 million blocks came back identical. The rest differ in properties Bedrock doesn't store because the game recalculates them, like whether a door is powered or a grass block has snow on top. Converted structures were also placed on a Bedrock Dedicated Server and checked block by block, and the Java files were loaded through 26.3's own structure loader.
Two of those missing properties matter on Java, so the converter works them out from the neighboring blocks the way Java does. Leaves get their distance from the nearest log, because Bedrock doesn't keep it and a leaf left at the default distance can decay after a paste. Chests side by side become a double chest again: Bedrock pairs them by itself when it loads a structure, but Java needs the pairing written into each half.
Java files come out readable by old and new versions alike. Minecraft 26.3 renamed the keys a structure file uses for its blocks, and a file stamped with 26.3's data version but written with the old keys loads as air. The converter writes both sets, so one .nbt loads in 1.21 and in 26.3. Older files with block names Java has since retired, like grass_path, are renamed on the way in.
For Bedrock on Windows, take the single .mcstructure: a structure block in Load mode has an Import button there. Phones and consoles have no import button, so pick Bedrock pack, which puts every converted structure in one .mcpack and names the command that loads each. For Java, .nbt is what structure blocks, /place template and data packs read, .schem is for WorldEdit and FastAsyncWorldEdit, and .litematic is for Litematica.
Files never leave your browser, so a big schematic doesn't wait on an upload. Structures up to 16 million blocks convert, and past 150,000 blocks the 3D preview is skipped to keep the page responsive. To move a whole Java data pack across, structures included, use the pack converter, which turns it into a Bedrock add-on.
Drop the .schem, .litematic or .nbt file in, leave the output on Bedrock .mcstructure and download it. On Windows, place a structure block, switch it to Load mode and import the file. On phones, consoles and anywhere else, pick Bedrock pack instead, import the .mcpack, turn it on in your world's behavior packs and run /structure load mcmaps:<name> ~ ~ ~.
Yes. Drop the .mcstructure in and choose Java .nbt, .schem or .litematic. Mojang's own Bedrock structures, the sulfur springs, convert with every block present, and all 10,957 of their blocks load in Java 26.3 exactly as the converter wrote them.
Between editions, what a block stores beyond its state: chest and barrel contents, sign text, spawner settings and the like. Bed and banner colors, the plant in a flower pot and double chests do carry over. Between Java formats nothing a block stores is lost, so a .schem turned into a .nbt keeps its chest loot and signs. Entities such as mobs, armor stands and item frames aren't converted either way.
A .nbt goes in a world's generated/minecraft/structure folder, or a data pack's data/<namespace>/structure folder, and loads with a structure block or /place template. A .schem goes in WorldEdit's schematics folder and loads with //schem load. A .litematic goes in Litematica's schematics folder.
No. Those use the number ids from Minecraft 1.12 and older. Load one into WorldEdit on any version since 1.13 and save it again as .schem, then convert that.
The Structure Viewer shows every structure Java ships, block by block.
