// Detailed reference
Yes. Your explored terrain, your builds, your chests and what is inside them, your items, your player, your mobs, your tamed animals, your villagers, your maps and your redstone circuits arrive in the other edition in the state you left them. When a piece of data cannot cross as-is, we tell you which one and why, further down this page.
You will find the details here, in both conversion directions: what arrives as-is, what needs an adaptation, what Minecraft recomputes by itself, and the little that does not exist at all in the other edition.
If you play vanilla (a base, farms, chests, animals, a village, a few hundred hours), you get back what you built and what you carry. You wake up at home, at your position, with your inventory, your XP, your active effects and your bed as respawn point.
What no converter can recover is terrain you never walked through: it was never written to your disk, so there is nothing to convert, and the target edition will generate it its own way. Hence the useful habit before exporting: go take a walk through the areas you care about. The rest of the differences are listed below, each with what is kept and where the limit comes from.
Blocks, entities, inventories, maps, chunks: nothing is stored the same way on both sides. So renaming a file extension converts nothing. Every piece of data has to be read and rewritten in the format the other engine expects, knowing the differences down to the detail: the order of the sherds on a decorated pot, how a bee remembers its hive, or the fact that a timer counts down on one side and points at a deadline on the other.
That is the work WorldSwitch does, and it is what lets this page go into this level of detail.
Geometry is the easy part. What makes a world yours is more like everything that was still in progress when you quit the game.
While converting, the engine records everything it could not reproduce identically: a property the target version does not know yet, a state with no equivalent, data set aside to allow the trip back. Every family is named and counted, instead of being summed up in a vague warning.
You read it in two places. On the final screen first: the number of recorded differences appears as soon as the conversion is done, and if your world contains experimental Bedrock content, we tell you which experiment to enable BEFORE opening it. In the converted world next: a file named worldswitch_command_report.json is dropped at its root, with the detail family by family. The total there is always exact; the detail covers the 200 most frequent families, and the file itself tells you how many are left beyond that.
Everything you already explored comes with you, across all three dimensions.
Every area already generated is rebuilt block by block: your landscape, caves, mineshafts, paths and everything you built there arrive in place, at the same coordinates.
Two bounds frame this promise, and each has its own card below: the height available in the target edition, and the blocks the target version can describe (your pick towards Bedrock, the tested Java version towards Java).
The Overworld, the Nether and the End are converted together, with their builds, their chests and their inhabitants. Your portals stay aligned.
The three dimensions do not have the same height from one edition to the other: the Nether case has its own card below.
The biomes of explored areas are converted along with your terrain. Your blocks and builds are never replaced because a biome had to be adapted.
When a biome exists on both sides, its counterpart is used. When it exists in only one edition, WorldSwitch keeps the closest available biome. The difference then shows up in what depends on the biome: grass and water tint, ambient sound, local weather, natural spawns.
A Java / Bedrock difference The two editions do not carry exactly the same biome list.
A flat world stays flat and a void world stays void: the composition, order and thickness of your layers are kept, along with the biome when it exists on both sides.
What gets generated AROUND afterwards is another matter: "generate structures", features, lakes and structure overrides are not described the same way in both editions. Your source world's setting comes back if you convert back, but the target edition may place structures where the other did not. A layer made of a block the target version does not know yet falls under the "target version" card below: the case is flagged, never silent.
Your terrain does not shift by a single block: a border is only a rule laid over the world, and everything it enclosed arrives intact.
Bedrock has no world border: the converted world opens unbounded. Your border is kept alongside the world (center, size, safe zone and damage) and comes back unchanged if you convert back to Java. Since Java 1.21.9 each dimension can have its own: a border specific to the Nether or the End is flagged in your conversion report.
A Java / Bedrock difference The border is a feature Bedrock simply does not have.
Your terrain, your builds and everything inside as well as outside the border arrive intact, at the same coordinates.
A world born on Bedrock has no border to give: the feature does not exist in that edition, so the Java world opens unbounded, just as it did on Bedrock. A world that started on Java gets its exact border back: center, size, safe zone, damage and warning distance.
A Java / Bedrock difference It is Bedrock that has no border; Java describes one perfectly well.
Your torches, lanterns, lamps, light blocks and stained glass all arrive exactly where you placed them.
The light map itself is not copied from one engine to the other: Minecraft recomputes it the first time the chunk loads, and the result is the target edition's normal lighting.
State the game recomputes The game redoes this computation, not us, and it redoes it on every version update anyway.
Blocks keep their orientation, their state and their pending timers.
Every block keeps its orientation. A log placed sideways stays sideways, a stair still faces the same way, and a door you left open still opens on the right side.
Wool, concrete, terracotta, stained glass, carpets, beds, candles and banners keep their exact color, both ways.
A slab placed on top stays on top, an upside-down stair keeps its orientation, and a door keeps its hinge on the right side.
A stair, fence, slab or sign placed in water stays waterlogged after conversion, and bubble columns keep their direction.
Your copper blocks keep their look, from brand new to fully oxidized, with the exposed and weathered stages in between. And if they are waxed, they stay waxed.
Wheat, beetroot, carrots, melons, cocoa, bamboo, cactus: every plant resumes at the exact growth stage you left it at, and tilled soil keeps its moisture level.
Repeaters, comparators, observers, pistons (base and head), levers and torches keep their orientation, their delay and their powered state. Your circuits restart the right way round.
The signal strength running through each redstone dust is kept, from 0 to 15.
Rails, powered, detector and activator rails keep their shape (curve, slope) and powered state.
A repeater mid-flip, water or lava mid-flow, frosted ice mid-melt, a crop about to grow: pending timers are converted with the right remaining delay.
The piston, its arm and the block it was moving all three arrive, in place, facing the right way: nothing drops on the ground and nothing turns into air.
The animation itself is not replayed: the carried block is placed on its DESTINATION cell, the one the game would have given it two ticks later. In practice you get the result of the push, not its intermediate frame, and a flying machine stopped mid-cycle may need one pulse to restart.
A Java / Bedrock difference The two editions describe a moving block with entirely different schemas. Copying Java's made the piston drop as an item and the pushed block turn to air: resolving the push is what keeps the build whole.
All your components arrive, oriented, powered and timed as you left them: the circuit is physically identical, block for block.
Java and Bedrock do not resolve redstone in the same order. Builds that rely on that detail (quasi-connectivity, BUDs, flying machines, very tight clocks) can behave differently in game, and sometimes need a tweak.
A Java / Bedrock difference It is the game engine that differs, not the world file: no converter can change that, whichever one you use.
It is not just the block that moves: it is what is inside it.
A lit furnace keeps its ongoing smelt, its remaining fuel and the accumulated experience waiting inside. Smokers and blast furnaces too, with their own speed.
Java remembers WHICH recipes produced that experience, Bedrock only the TOTAL. From Bedrock to Java the total is therefore spread over one reference recipe: you collect the right amount of XP when emptying the furnace, without the itemized list. And a smelting recipe with a custom duration (datapack) resumes at the vanilla duration.
A Java / Bedrock difference The two editions do not store a furnace's experience at the same level of detail.
Each of the four slots keeps its food AND its own cooking timer: the meat that was nearly done stays nearly done.
A brewing stand keeps its brewing potions, its blaze powder, its water and the remaining brew time.
A brewing stand whose total brew time was changed by a datapack resumes at the vanilla duration: the brew in progress continues, at the game's normal speed.
A Java / Bedrock difference Bedrock has no way to describe a custom brew duration.
An active beacon keeps its beam, its primary and secondary powers, and its pyramid level. Everything is there from the first load, with nothing to rebuild.
A lectern keeps the book placed on it and the exact page it was open at.
Every book stays in its exact slot, out of the six: the comparator behind your secret door will read the same value.
The inserted disc stays in the jukebox. The track restarts from the beginning when you play it again: the game plays the sound, it is not stored in the world file.
A beehive keeps the bees stored inside, each with its own state, along with its honey level.
The text, the 16 colors, bold, italic and the glowing effect of BOTH sides of a sign are kept, hanging signs included, and the wax too.
Two kinds of formatting have nowhere to go. Java's underline and strikethrough no longer exist on Bedrock: those two codes now name material tints there (copper, redstone). The other way round, those same tints have no Java color name. Either way the text, its base color and its formatting stay, and the case is named in the report.
A Java / Bedrock difference Bedrock reassigned the underline and strikethrough codes to colors. Emitting those codes for a Java style would give a wrong hue, not an underline.
A banner keeps its layered patterns, in order, with their colors, and its rotation on its post. Ominous banners and pillager banners too.
Both editions share the vanilla patterns. If one of them just added a pattern the other does not have yet, that single layer is the only one affected: it is named in the conversion report, and the banner keeps all its other layers and its place.
A version difference The two editions do not add new patterns at the same time.
A decorated pot keeps its four sherds, each on the right face and the right way round, along with its contents. A flower pot keeps its plant.
Since Java 26.3, a pot face can carry a sherd renamed at an anvil: Bedrock only records the sherd's identifier, so the motif is there but not the custom name. The case is named face by face in the report.
A Java / Bedrock difference Bedrock stores one identifier per face, where Java stores a full item.
A frame keeps its displayed item and its rotation; a glow frame stays glowing. A painting keeps its motif, its size and its wall.
A spawner keeps the mob it spawns and all its settings: delay, activation range, count per wave.
A spawner set to pick between SEVERAL mobs keeps only the main one: the most likely in its list. The spawner itself works normally.
A Java / Bedrock difference The two editions do not describe a weighted draw between several mobs the same way.
Vaults and trial spawners are converted with their contents: the list of mobs they spawn, their normal and ominous settings, the selected reward table and the players already registered.
For a Bedrock → Java conversion, provide your Java ID: that is what lets a vault you already opened stay opened for you. Without it, it may offer its reward again.
A Java / Bedrock difference A vault remembers WHO opened it, and the two editions do not identify players the same way.
The trial spawner arrives in place, with its mobs, its settings, its reward table and the players it had registered: your trial chamber stays playable from end to end.
If you leave the world mid-wave, the trial does not resume in the middle of that wave: it returns to its waiting phase and re-arms when you come close. You run it again from the start, for the same loot.
Current WorldSwitch limit This is a WorldSwitch precaution, not an edition difference: an advanced phase state written with partially translated contents made Bedrock CRASH when approaching the spawner, in game. We prefer a trial to redo over a world that closes.
Every slot, every stack, every nested container.
The contents of chests, double chests, barrels, hoppers, dispensers, droppers and shulker boxes are transferred slot by slot, in the right order.
A shulker box or a bundle stored in a chest keeps all its contents, with the enchantments and wear of every item inside, dyed bundles included. The nesting holds all the way down.
A dungeon, temple, ruined portal or shipwreck chest you have not opened yet keeps its loot table: it still has its surprise for you, and the surprise will be the target edition's one.
Your hotbar, bag, armor and off-hand are transferred as-is, with the enchantments, wear and custom names of every item.
The 27 slots of your personal ender chest are kept.
An item is more than a name: its wear, its enchantments and its history follow.
The 42 enchantments WorldSwitch knows are converted with their exact level, on your tools, weapons, armor and books, including levels beyond the vanilla maximum. The named list is at the bottom of this page.
One Java enchantment is missing from it: Sweeping Edge, which Bedrock has never had. A sword carrying it goes through the conversion with everything else (its name, its wear, its other enchantments) and the report names the enchantment removed.
A Java / Bedrock difference Bedrock has no Sweeping Edge: there is no identifier to translate it into, and inventing one would make the item unreadable.
The wear of your tools, weapons and armor is kept to the point: a half-broken pickaxe stays half-broken, and its anvil repair cost follows.
An item renamed at an anvil keeps its name, and item descriptions (lore) are kept line by line.
The 45 potion variants WorldSwitch knows (normal, extended, strong) are converted, as a bottle, a splash potion, a lingering potion or a tipped arrow.
A signed book and quill keeps its text page by page, its title and its author. An enchanted book keeps all its enchantments and their levels.
Rockets keep their flight duration, their explosion shapes, their effects (twinkle, trail) and their colors, fade colors included. A firework crafted in game goes off exactly the same.
Java allows any color, Bedrock works with the 16 dyes. A color built with commands, outside those 16, is matched to the closest dye: that shows on a map with bespoke colors, not on a normally crafted rocket.
A Java / Bedrock difference Bedrock names firework colors by dye, not by a free value.
An item stays your item: its identity, its count, its name, its wear and its enchantments make it through the conversion.
The components Java introduced in 1.20.5 do not all have a Bedrock counterpart. Some only touch appearance (custom model, tooltip color, display flags): the styling drops and the item stays. Others define its BEHAVIOR: an item made edible, gliding, wearable in an unusual slot, or whose max stack size was redefined by command. That one does arrive in your inventory, but it falls back to the vanilla behavior of its identifier. Every component involved is named in the report, and the report tells the two cases apart.
A Java / Bedrock difference Java rewrote how it describes items in 1.20.5; Bedrock does not follow the same model.
A player head stays a player head, placed exactly where you put it, with its rotation.
The skin it shows depends on an online account specific to each edition: it may not carry over, leaving a head with the default face.
A Java / Bedrock difference The face is not stored in the world, it is fetched from that edition's servers.
You wake up at home, with your stuff and your level.
You reappear in the same place you logged off, in the right dimension and facing the same way.
Your XP level and how full your experience bar is are kept exactly.
Your health points, hunger bar, saturation, remaining air and current fall are transferred.
The 37 effects WorldSwitch knows (speed, strength, fire resistance, poison, absorption, levitation, the omens…) are kept with their level and remaining duration, on you and on your mobs.
Four Java effects have no Bedrock counterpart: Glowing, Luck, Bad Luck and Dolphin's Grace. When one of them is active at save time, it stops there (as it would have stopped when its duration ran out) and it is named in the report. All your other effects keep running.
A Java / Bedrock difference Those four effects do not exist in Bedrock: there is no identifier to translate them into.
Your respawn point comes along, at the same coordinates and in the right dimension, whether you sleep in a bed or use a respawn anchor in the Nether.
Two of Java's fine settings have no Bedrock field: the direction you face when you respawn, and the flag that forces the respawn even if the bed was destroyed. They are kept alongside the world for a trip back to Java; on Bedrock you respawn in the right place, simply facing the default direction, and Bedrock applies its own rule if the bed is gone.
A Java / Bedrock difference Bedrock describes neither the respawn angle nor that flag. We would rather archive them than invent a field.
Survival, creative, adventure or spectator: you get back the mode you were playing in, with the flight ability that goes with it.
The other players' profiles are preserved: inventory, armour, ender chest, XP, health, position and respawn point. Java and Bedrock don't use the same account system, so WorldSwitch lets you link each player to their target account when you know their ID.
If you don't know that mapping, the profile is not thrown away: it is preserved, and WorldSwitch can create a recovery copy of its belongings in the world, near spawn, never replacing an existing block. An unknown identity therefore never becomes a silent loss of inventory. Going Bedrock → Java, you enter each player's Java UUID before starting the conversion. Going Java → Bedrock, no linking is offered: with only the information a world carries, we cannot reliably attach a profile to an Xbox account, and we would rather not advertise a capability we cannot honour; the profile and the backup copy are there all the same.
A Java / Bedrock difference The two editions do not use the same account system, and no world file carries the mapping: it can only come from you.
Your speed, your reach, your luck, your knockback resistance: the EFFECTIVE value of each of your attributes is carried over exactly as you had it, including when a potion, an enchantment or a datapack had changed it.
Java stacks those bonuses as separate modifiers, each with its own duration; Bedrock keeps no such list on the player. WorldSwitch therefore folds their effect into the base value: you arrive with exactly the same numbers, but a bonus that was meant to EXPIRE becomes permanent on Bedrock. The report names every attribute involved. A value outside the range Minecraft allows is brought back into it, the same way the game does.
A Java / Bedrock difference Bedrock has no modifier list on the player: there is nowhere to write "this bonus expires in two minutes".
Your position, your view direction, your health and all your gear are carried over as-is.
If the world was saved while you were crawling, swimming or gliding, the game may stand you up on load. You are in the same place, in the same second of play.
State the game recomputes Posture is a momentary state the engine recomputes on every load, conversion or not.
152 entity types, with what makes them yours.
The engine handles 152 entity types: 90 living creatures (animals, monsters, villagers, bosses) and 62 other entities (vehicles, projectiles, frames, paintings, dropped items). The full named list is at the bottom of this page.
A sheep's color and whether it is already sheared, a cat's or wolf's collar, the variant of a rabbit, fox, axolotl, frog or tropical fish are kept.
Your tamed animals (dogs, cats, horses, parrots, llamas) stay tamed, sitting or standing as you left them, with their health and their name.
Your dog stays your dog: tamed, named, sitting where you left it, with its collar in the right color.
It may no longer recognize you as its owner on first load. Providing your Java ID for a Bedrock → Java conversion clearly reduces that risk.
A Java / Bedrock difference The bond points at a player account, and the two editions do not identify accounts the same way.
A horse's variant and color, its saddle, its armor, a donkey's chest and its contents, a llama's carpet, a pig's or strider's saddle: it all follows. And a mount keeps its riders.
A skeleton with an enchanted bow, a helmeted zombie, an enderman holding a block: gear, main hand, armor and carried block are kept.
A baby stays a baby, with the time left before it grows up, and an adult that just bred keeps its cooldown before it can breed again.
One case does not follow: a baby whose ageing was LOCKED by command, so it stays small forever. Bedrock cannot lock an age: that baby will grow up normally. The lock is kept alongside the world, so a trip back to Java finds it intact.
A Java / Bedrock difference Bedrock has no age-lock field on a native mob: inventing one would be a gamble, not a conversion.
A renamed mob keeps its name above its head, with its formatting: your animals and mini-bosses stay recognizable at a glance.
Java can additionally require a name to be rendered PERMANENTLY, even through walls and without looking at the mob. Bedrock shows names by its own rule: the name is there, its forced permanence is not. The Java intent is kept alongside the world, so a trip back to Java finds it again.
A Java / Bedrock difference Bedrock's visibility field is a constant on every named mob, as read from native worlds: it does not carry Java's "always shown" intent.
An animal on a leash stays attached after conversion, whether it is tied to a fence post or held by you.
A burning mob keeps its fire, a poisoned mob its effect and duration, a charged creeper stays charged, and an angry piglin or wolf still arrives angry, at the same target.
What gets adjusted is how long it stays angry. Java counts the remaining anger ticks, Bedrock only remembers WHO the mob is angry at. A mob from a native Bedrock world therefore restarts on a standard anger duration; one from a world already run through WorldSwitch gets its exact counter back.
A Java / Bedrock difference Bedrock stores no anger counter on a native actor: the target exists on both sides, the duration does not.
A mob heading to Bedrock carries the group list the game itself writes on a mob of the same species. That list is what gives it back its behavior, its shape and its gear when the world is reopened.
Bedrock stores those groups in the save file and does not recompute them on load; Java describes the mob field by field, with no counterpart. So we compose no list of our own: the ones we write are measured on the Bedrock engine itself, species by species. When a mob's exact state was not measured (the baby of a species where only the adult form is known, a horse coat outside the measured values), it leaves in its species' default state and the report names it.
A Java / Bedrock difference The two editions do not describe a mob the same way, and a hand written list missing one group leaves the game unable to pick a shape.
The mob is there, at its exact position, with its health, its name, its gear, its age and its effects.
The path it was computing and the target it was chasing are not saved data: it takes its decision again on the first tick, exactly as after any reconnection.
State the game recomputes Minecraft itself does not store an AI's in-progress decision in the world file.
The hive arrives with its bees, their state and its honey level. The bees find their hive again and go back to foraging.
On Java, the hive memorizes the exact flower its bees were visiting; on Bedrock, the bees themselves remember their anchor point. So we do not fabricate an invented field: the value is kept alongside the world for a trip back to Java, and in game the bee picks a new flower.
A Java / Bedrock difference The two editions do not store this information in the same place. Inventing a Bedrock field that does not exist on a native hive would be a gamble, not a conversion.
A village is not a pile of houses: it is a network of jobs, beds and workstations.
The profession (farmer, librarian, cleric…), the exact level (novice through master), the trading experience already earned and the biome outfit of your villagers are kept. The level thresholds travel with them: a converted villager keeps levelling up normally instead of being stuck at the level it had.
One exception towards Java: a novice villager that has never traded and has no workstation of its own goes back to having no profession as soon as Java loads it, and loses its novice trades. It will take a job again when it finds a free workstation. We do not assign one at random. Your conversion report says how many villagers are affected. A villager that has already traded or levelled up keeps its profession, workstation or not. Another difference seen on a real Java 26.3 server: in a very narrow trading cell where several villagers are crammed together, Java can push one of them into a wall, where it suffocates. A villager born in Java at the same spot suffers the same: leave one free block per villager.
A Java / Bedrock difference Java removes the profession of a novice without a workstation that has never traded; your Bedrock world let it keep it.
Every UNLOCKED trade is kept: what the villager asks for, what it sells, the quantities, the enchantments on the book on offer and the uses left. The discounts of a villager you cured from zombification follow you too. With your Java account UUID, they arrive exactly as in game, original price struck through included.
Without a Java account UUID, the reduced price you were paying is kept, but it is built into the trade price: no struck-through price, and if demand for that trade changes later, the price may drift slightly from what the other edition would have computed. Tiers the villager has not reached yet are not carried over: Java cannot display a locked trade, and hands them back as it levels up.
A Java / Bedrock difference Java ties a discount to the player who cured the villager, through their account UUID; Bedrock stores it on the villager itself.
The beds, bells and workstations that make a village a village are converted with their occupancy: who sleeps where, who works at which station. A villager finds its bed and its job again instead of everything being reassigned at random.
A raid interrupted by the save resumes where it was: the current wave, the raiders already there with their group and their captain, the progress bar and the bad omen on your player. The raid is neither declared won nor lost on your behalf.
The two editions do not tie a raid to its village the same way: Java tracks each villager by its point of interest, Bedrock reasons over a village box. The village that owns the raid is therefore rebuilt from the villagers, golems and cats converted around its center, otherwise Bedrock would judge the village empty and cancel the raid on the first tick. A very spread-out village may be grouped slightly differently.
A Java / Bedrock difference The two editions do not describe a village with the same objects. Rebuilding is what lets the raid survive the load; copying it as-is would get it cancelled.
Including what was already mid-flight when the world was saved.
Every boat wood type, bamboo rafts, chest boats and their contents, storage, hopper and TNT minecarts arrive in place, with their riders, mob or player.
An arrow stuck in a wall, a thrown trident, an ender pearl in flight, a splash potion mid-arc, primed TNT with its countdown, an End crystal, a lingering cloud fading out: everything airborne at save time arrives at its position, with its velocity, and with its shooter whenever that link exists on both sides.
The two editions do not describe a projectile with the same granularity. A splash or lingering potion in flight receives the fields Bedrock does have (its effect, its radius, its duration) and the full Java description is kept alongside the world, so a trip back to Java recovers it whole.
A Java / Bedrock difference Bedrock's description of a projectile is shorter than Java's: what has no field is archived rather than invented.
The bobber stays on the water, linked back to the right angler.
The arrow stays: stuck in the scenery or mid-flight, with its trajectory and its shooter.
Bedrock has no spectral arrow: it arrives as an ordinary arrow, without the glowing outline effect.
A Java / Bedrock difference That projectile simply does not exist in Bedrock.
The drawing itself, not just the item.
Your explored maps are converted pixel by pixel (128 × 128), with their scale, center, dimension, locked state and the banner and frame markers placed on them. What you uncovered stays uncovered.
Java describes each pixel by a palette entry, Bedrock by a free color. Coming from Bedrock, each pixel therefore joins the closest Java palette entry: the drawing, the terrain and the shading are there, a few shades may be very slightly off. And where Java distinguishes each explorer map type (ocean, mansion, trial…), Bedrock has just one map: the drawing and the marker follow, the type label does not. One Java-only tracking flag is kept alongside the world for the trip back.
A Java / Bedrock difference The two editions do not store a map in the same color format: Java's palette and Bedrock's colors do not overlap exactly.
Every map stays in its frame, in its place and with its rotation: a 3 × 3 map wall stays a 3 × 3 map wall, and each tile still shows its own piece.
A structure's already-generated blocks are kept as soon as they exist in the target version. It is the structure's internal label that differs by direction.
Fortresses, monuments, temples, outposts, trial chambers: the blocks, chests, items and already-generated mobs are kept.
The structure's internal identity is rebuilt from what Bedrock records in its chunks: Java therefore knows again that this corridor belongs to a fortress, which matters for structure-specific spawns and for `/locate`.
Your fortress stays your fortress: every block, every chest, every item, every mob already there makes it through the conversion, and the internal label telling Minecraft "this chunk is part of a fortress" is now written back everywhere Bedrock can hold it. Nether fortress, monument, swamp hut, pillager outpost, igloo, trial chambers and trail ruins therefore get their structure-only spawns back.
Seven structure families carry that label on Bedrock, and they are exactly the ones we write: fortress, monument, swamp hut, pillager outpost, igloo, trial chambers, trail ruins. For the others (village, mineshaft, stronghold, mansion, shipwreck, buried treasure, temple, ancient city, ruined portal, bastion, end city), Bedrock records no such label: there is nothing to write, and nothing gets lost on the way since nothing existed. What matters to you, the build and its contents, arrives intact. Villages have their own separate system on Bedrock, and that one is converted.
A Java / Bedrock difference This is an edition difference, not a WorldSwitch limit: Bedrock only tracks those structures per chunk for seven families. Measured rather than assumed — across two Bedrock worlds from our corpus and two freshly generated worlds, with the structures actually placed, no other family ever produced that data.
Settings the two editions share are carried over as-is.
The seed is kept. It only drives terrain not yet explored: what you already visited comes from your world, not from a regeneration.
Rules recognized by both editions (day/night cycle, fall damage, keepInventory, mobGriefing, fire, TNT, PvP, command blocks, sleeping percentage…) are kept with their value.
A rule that exists on only one side has nowhere to go: Java has some thirty that Bedrock does not (portals, command reach, entity cramming…), and the reverse is true too. Those are listed in your conversion report. Since Java 26, fire spread is set by a RADIUS around the player where Bedrock only has a yes/no: fire stays on or off as it was, but without the radius notion.
A Java / Bedrock difference The two editions do not carry the same list of rules.
The difficulty level (peaceful, easy, normal, hard) is kept, and a hardcore world stays a hardcore world, both ways.
The in-game time, the current weather (rain, thunderstorm) and the world age counter are transferred: you resume at the same moment of the same day.
Your world keeps its name in the world list, and its shared spawn point (where new players arrive) is kept.
Flat worlds, with the composition and thickness of their layers, and void worlds are kept. Your already-explored terrain arrives just as you left it.
"Large biomes" and "amplified" do not exist on Bedrock: terrain generated LATER, beyond what you visited, will be normal terrain.
A Java / Bedrock difference Those two generation modes only exist in Java.
For command-driven maps: the fine print starts here.
Command blocks are converted with their mode (impulse, chain, repeat), their conditional flag, their name, their powered state and their last output, and their vanilla commands are rewritten into the target edition's syntax.
Timing does not always cross. Bedrock can delay any command block and can also tell it to skip the first tick; Java has a native interval only on the repeating block. When that timing has no faithful Java form, the block arrives DISARMED rather than firing at the wrong rate: its command is handed back to you in the report, with its position and original delay, so you can rewire it with a clock. In Java → Bedrock, some information attached to a command has no equivalent. When WorldSwitch can remove it without changing the main action, the target or the conditions that decide whether the command runs, it keeps the command without that information and reports the difference. If removing it could broaden a test or filter, target something else, change the main action, or if the command is malformed, the block stays DISARMED and the original command is reported.
A Java / Bedrock difference The two editions do not schedule time the same way and cannot express all the same information inside a command. WorldSwitch removes unsupported information only when the main action, target and execution conditions stay the same; otherwise it disarms the block and reports the case rather than letting the command change role.
Selectors and their common filters are translated into the target edition's syntax: @p, @a, @e, @s, @r, tag=, name=, type=, scores=, distance=, limit=, sort=, gamemode=, view angles and volumes, including the forms Bedrock spells differently.
Four filters exist only on Java (`nbt=`, `predicate=`, `advancements=`, `team=`) along with entity-tag targeting (`type=#minecraft:raiders`). When one shows up, the command is never copied over blindly. Inside a command text it is replaced at its exact spot by a comment naming the filter at fault. Inside a command block, an item or a minecart (where Bedrock has no comment syntax) the block arrives disarmed and the explanation reaches you in the report, with its position and the original command.
A Java / Bedrock difference Those filters query systems Bedrock does not have. Copying an invalid selector would make the command fail silently.
Text components are translated between Java's JSON format and Bedrock's rawtext format: colors, bold, italic, nested text, translated strings with their arguments, inserted scores and player names resolved by a selector.
Two things find no destination on Bedrock. INTERACTIVE text first: a click that runs a command, a hover tooltip, text inserted on click, a custom font, keybind display, data reads. UNDERLINE and STRIKETHROUGH next: Bedrock reassigned those two codes to material tints, so there is no style left to aim at. Either way the message stays, its color and bold stay, and the component at fault is flagged at its location instead of turning into an empty rawtext.
A Java / Bedrock difference Bedrock's rawtext has no interactivity field, and its underline codes now serve another purpose: there is nothing to translate a click, a hover or an underline into.
A structure block keeps its name, mode, size, offset, rotation, mirror and integrity, that last value being rewritten in the target edition's scale.
Objectives, every player's scores and the display slot (sidebar, player list, below name) are converted, title included.
Java TEAMS (color, prefix, suffix, friendly fire, collision, member list) have no Bedrock counterpart: they are not transferred. Scores themselves stay intact.
A Java / Bedrock difference Bedrock has no scoreboard team system.
Your command blocks, your scores, your signs, your trapped chests and the whole build of the map are converted normally.
Custom boss bars and scheduled world events are Java-only systems: they have no destination on Bedrock. Chunks kept loaded, on the other hand, exist on both sides, and they now cross over in two ways. The world STATE (the chunks you actually forced) becomes real ticking areas, described by the "chunks kept loaded" card. And the COMMAND itself is rewritten, `/forceload add` into `/tickingarea add`, `/forceload remove all` into `/tickingarea remove_all`, `/forceload query` into `/tickingarea list`, the way back retracing the same path. Inside a command, five forms have no destination and are flagged where they stand instead of being copied over: removing a RECTANGLE of columns, querying ONE column, Bedrock's CIRCULAR area, its PRELOAD flag, and a rectangle over 100 chunks, which the Bedrock engine refuses.
A Java / Bedrock difference The first two do not exist in Bedrock. The third exists on both sides, which is why it is converted; the five remaining forms are real grammar or cap differences, since Bedrock removes an area by position or by name, never by rectangle, accepts no more than 100 chunks per area, and Java knows neither discs nor preloading.
The chunks you forced to stay loaded stay loaded in the target edition: on Bedrock they become real ticking areas, written into the world, and on the way back to Java they become forced chunks again. So your farm keeps running while you are on the other side of the map.
Bedrock counts in rectangular AREAS, not lone chunks, and it sets two caps: 100 chunks per area, 10 areas per world across all dimensions. A large Java rectangle is therefore split into several areas, losing nothing. Very SCATTERED chunks, however, would need more than ten areas: the largest are written, and the conversion report tells you exactly how many chunks are left out. During your Bedrock session those chunks are not kept loaded; they load again when a player comes near. On the way back to Java the two halves follow different rules, on purpose: a chunk that HAD its area follows the Bedrock state (if you deleted the area while playing, it does not come back, that is your decision); a chunk that never had an area existed nowhere on Bedrock, nobody could touch it there, so it is kept alongside the world and it comes back. An area you ADD on Bedrock reaches Java the same way.
A Java / Bedrock difference Both caps are the Bedrock engine's own, measured on the official server, not WorldSwitch choices: beyond them, it is the engine that refuses the area.
Vanilla commands are translated from one syntax to the other, including the awkward cases: relative and local coordinates, block states, NBT, dimensions, sounds, recipes, effects.
When a command simply does not exist in the target edition, it is never copied over as-is. Inside a command text it is replaced at the exact spot by a comment saying what was missing. Inside a command block, where no edition accepts a comment, the block arrives disarmed and the report hands you its position and original command: you see what to rewire instead of hunting for why the map no longer starts.
A Java / Bedrock difference The command does not exist in the other edition; inventing a rough translation would break the map silently.
Minecraft moves constantly. WorldSwitch writes for the version your world will open in, and warns you instead of guessing.
Towards Bedrock, you can pick among the target profiles offered. Towards Java, WorldSwitch automatically uses the stable Java version currently tested, today Java 26.3. Blocks, their states and commands are validated for the target actually used. That is what avoids the classic converted world that refuses to load.
One family is deliberately left out of that filtering: ITEMS. An item identifier our target-version registry does not know is kept as-is rather than replaced, because substituting blindly has already made perfectly valid items vanish, Minecraft carrying legacy identifiers no registry lists. The item therefore arrives in your chest, and the report tells you which one might not exist in your version. Blocks, states and entities are indeed adapted or flagged.
Current WorldSwitch limit This is a deliberate WorldSwitch choice: between deleting an item that may well have existed and letting it through with a warning, we would rather destroy nothing. Towards Bedrock, picking the most recent profile closes the subject; towards Java, the target already is the most recent tested version.
The content of the very latest drops (dappled forest, poplars, cushions, straw beds, wool stairs…) is kept in your world. We do not replace it with air: deleting your build would be irreversible, ticking a box is not.
On Bedrock, this content lives behind an experiment you have to enable. WorldSwitch tells you at the end of the conversion which one to enable, before opening the world, and warns you that enabling an experiment disables that world's achievements, permanently.
A version difference On Java the same content is ordinary; on Bedrock it sits behind a toggle. The content being there says nothing about the toggle's state.
Your block stays placed, in position, with its orientation; your item stays your item; your mob stays your mob, with everything the target version can describe.
If Mojang just added a block property, an enchantment, an effect or the contents of a brand-new block, and the target version does not know it yet, that unsupported part is removed rather than making the block or the whole chunk get rejected. An ITEM is different: it keeps its identifier and still arrives in your chest; the "target version" card explains why. Every affected case appears by name in the report, with its occurrence count. A concrete example: Java 1.21.5's "Spring to Life" vegetation (bush, cactus flower, firefly bush, leaf litter, dry grass, wildflowers) has existed in Bedrock since 1.21.70; it therefore goes through without a word if you target a recent version, and is only flagged on an earlier target.
A version difference The two editions do not move at the same pace; writing an unknown property gets the block rejected, sometimes the whole chunk. Targeting a recent version is often the answer.
They are few, they are not hidden, and each card says what stays and what changes. The report shipped with your world names and counts the gaps actually recorded on yours.
Everything you explored comes with you, block by block: your bases, your farms, your roads, your mines. Nothing you have seen gets regenerated.
Terrain you never visited exists in no file: it will be created by the target edition, with its own generator. And since Java and Bedrock do not generate the same way, the same seed gives a different landscape there: a seam may be visible at the edge of what you explored.
A Java / Bedrock difference That terrain was never written to your disk: there is nothing to convert. The right move: go walk through the areas you care about before exporting.
A Bedrock world created before 1.18 converts normally. Only terrain still stored in the format from before Bedrock 1.2.13 is not read: the conversion then stops with a clear message, rather than handing you a world full of holes.
Bedrock only rewrites a piece of terrain when it loads it. Areas never reopened since the very first versions therefore stay in a very old format, which WorldSwitch does not read. Turning them into empty space would be a silent loss: the message counts those areas and explains what to do.
Current WorldSwitch limit Current WorldSwitch limit. Open your world in a recent Minecraft Bedrock and go load the old areas involved, so Bedrock rewrites them in its current format. Save, then export the .mcworld again. Reopening and saving without going there is not enough.
Your whole Nether is converted up to the bedrock ceiling: your roads, gold farms, portals and bases under the roof arrive intact.
Java's Nether is twice as tall as Bedrock's. What you built ABOVE the roof literally has no room in a Bedrock Nether, which stops at that height. Nothing is force-lowered: that would shift every coordinate around it.
A Java / Bedrock difference The two editions do not have the same Nether height. WorldSwitch counts what overflows and tells you, exact height included, in the conversion report.
Your world, items, XP and builds arrive intact. It is your career counters that reset, not your game.
Statistics (distance walked, mobs killed, play time) and unlocked advancements rely on different identifiers and different trees between the two editions. We also do not artificially turn your Java advancements into Bedrock achievements: that would be fabricating rewards you did not earn in that edition.
A Java / Bedrock difference The two editions share neither the same advancement list nor the same way of counting them.
The minecart stays on your rails, in place, and rolls normally.
Bedrock has no furnace minecart: it arrives as an ordinary minecart, without its ability to push a train on coal.
A Java / Bedrock difference That vehicle does not exist in Bedrock. It is not a missing mapping, the mechanic is simply not there.
Everything the two editions share makes it through the conversion, with its count, wear, enchantments and name.
Four creation tools have no counterpart: the debug stick, the knowledge book and the two test blocks. Each one is named in the conversion report, with its reason.
A Java / Bedrock difference We do not swap them for a lookalike: blind substitution has already made perfectly valid items disappear. We record and name instead.
The "allow", "deny" and "border" blocks become barriers on Java: the invisible wall stays exactly where you placed it, and it still blocks the way.
What Java cannot reproduce is the attached rule: allowing or denying building for a player in adventure mode. The resulting barrier blocks the way without carrying that permission.
A Java / Bedrock difference These three blocks belong to Bedrock and its build-permission system. The barrier is the closest real parent: it keeps the visible function.
The 152 entity types both editions share are converted, including mobs, vehicles, projectiles and decoration.
Display entities (block, item, text), markers and interaction zones are map-maker tools that only Java has. They do not arrive in the Bedrock world, and each one is named in the conversion report rather than vanishing without a word.
A Java / Bedrock difference No Bedrock actor matches them. Writing an entity Bedrock does not know crashes the chunk load: silence here would be worse.
The Overworld, the Nether and the End are converted in full, with everything they hold.
A dimension added by a datapack or a mod relies on content that lives outside the world. WorldSwitch does not rewrite it into an equivalent Bedrock definition: without that content it has no destination in the converted world, and a command that ran inside it is flagged at the exact spot where it sat.
Current WorldSwitch limit This is the same boundary as mods and datapacks: we convert the world, not the extensions that make it run.
A world is not a server. Here is the boundary, said clearly before you buy.
Terrain, vanilla blocks and everything you built with them are converted normally.
A mod is not world data: it is code running alongside the game, and it only exists on Java. The blocks and items it adds have no counterpart anywhere else.
A Java / Bedrock difference No converter can carry mod code to Bedrock, or the other way.
What a datapack already PLACED in your world as vanilla blocks stays in your world and converts like the rest.
The datapack itself (its functions, loot tables, recipes, predicates) is a Java-only system. It will no longer run after the conversion.
A Java / Bedrock difference Bedrock has no datapacks; its counterpart, add-ons, uses an entirely different model.
The world and all its vanilla content are converted normally.
Behavior packs and add-ons are a Bedrock-only system: they describe behaviors in JSON and have no Java equivalent.
A Java / Bedrock difference The two editions do not extend the game the same way.
Your world arrives complete; the game applies its default textures, and you can reinstall an equivalent pack in the target edition.
A world can embed its own pack: `resources.zip` or the `resourcepacks/` folder on Java, `resource_packs/` on Bedrock. WorldSwitch keeps it as-is alongside the converted world: nothing is thrown away, and it comes back intact if you convert back. It is not TRANSLATED though: models, textures and sounds do not share a format across editions.
A Java / Bedrock difference The pack is kept, but its format does not exist as-is in the other edition.
The world hosted on that server is converted in full: terrain, builds, chests, players, mobs.
What surrounds the world (`server.properties`, whitelist, operators, bans, permissions, plugins, startup scripts) belongs to the server software, not to the world.
A Java / Bedrock difference WorldSwitch converts the world; it does not transform the server software or the extensions around it.
A command is not decorative text: it is what makes your map work. And the two editions do not write it the same way. The same order ("give a sword to the nearest player", "put red wool here") is spelled with different words, different identifiers and different units on each side. Copying the text as-is would, in nearly every case, produce a command the other edition rejects. So WorldSwitch reads each command, understands it, and rewrites it.
Translating the command's name would achieve nothing on its own: almost everything inside it changes vocabulary too. Here is what the engine reworks, with real examples taken from the converter's own output.
kill @e[type=zombie,r=10,rm=2,c=3,x=0,y=64,z=0] becomes kill @e[type=zombie,x=0,y=64,z=0,distance=2..10,limit=3,sort=nearest]execute if entity @a[gamemode=survival,level=10..30,scores={obj=1..}] run say ok becomes execute if entity @a[m=survival,scores={obj=1..},lm=10,l=30] run say okfill ~ ~ ~ ~5 ~5 ~5 wool 14 replace air becomes fill ~ ~ ~ ~5 ~5 ~5 red_wool replace airsetblock ~ ~ ~ minecraft:repeater[delay=3,facing=north] becomes setblock ~ ~ ~ minecraft:unpowered_repeater ["minecraft:cardinal_direction"="north","repeater_delay"=2]give @p potion 1 5 becomes give @p potion[potion_contents={potion:"minecraft:night_vision"}] 1give @p minecraft:stone[minecraft:can_place_on={blocks:["minecraft:dirt"]}] 1 becomes give @p minecraft:stone 1 0 {"minecraft:can_place_on":{"blocks":["dirt"]}}summon minecraft:zombie ~ ~ ~ {IsBaby:1b} becomes summon minecraft:zombie ~ ~ ~ 0 0 minecraft:as_babysummon fireworks_rocket ~ ~ ~ becomes summon firework_rocket ~ ~ ~enchant @p 9 3 becomes enchant @p sharpness 3playsound random.levelup @a ~ ~ ~ 1 1 becomes playsound entity.player.levelup master @a ~ ~ ~ 1 1tellraw @a {"text":"Salut","bold":true} becomes tellraw @a {"rawtext":[{"text":"§lSalut"}]}titleraw @a title {"rawtext":[{"text":"Salut"}]} becomes title @a title {"text":"Salut"}setblock ~~1~ stone becomes setblock ~ ~1 ~ stonetp @p .5 64 .5 becomes tp @p 0.5 64 0.5execute in nether run say hi becomes execute in minecraft:the_nether run say hidamage @p 4 minecraft:dragon_breath becomes damage @p 4 magicSometimes it is not the contents that differ but the command itself: the same intent goes by two names. Copying the text would give a command that does not exist on the other side.
testfor @p becomes execute if entity @ptestforblock ~ ~ ~ wool 14 becomes execute if block ~ ~ ~ red_wooltestforblocks 0 0 0 1 1 1 5 5 5 masked becomes execute if blocks 0 0 0 1 1 1 5 5 5 maskedreplaceitem entity @p slot.armor.head 0 diamond_helmet becomes item replace entity @p armor.head with diamond_helmet 1item replace entity @p armor.head with minecraft:diamond_helmet becomes replaceitem entity @p slot.armor.head 0 minecraft:diamond_helmet 1xp 100L @p becomes experience add @p 100 levelsdaylock true becomes gamerule advance_time falsewhitelist add Steve becomes allowlist add Steve? give becomes help giveThere are still cases where the other edition has nothing to offer. The rule is then always the same, and this is the part that matters: the command is NEVER copied over blindly. An invented command that fails silently costs far more than a missing command that is flagged.
bossbar add test "Boss" becomes # unsupported: bossbarcamerashake add @a 1 1 positional becomes # unsupported: camerashakekill @e[nbt={Health:20f}] becomes # semantic loss: selector uses Java-only filter (nbt/predicate/advancements/team)kill @e[family=monster] becomes # semantic loss: selector filters need translation or explicit unsupported markerfunction mypack:test becomes # semantic loss: Java function belongs to a datapack, and datapack functions are not transferred to a Bedrock behavior packstructure load maison ~ ~ ~ becomes # semantic loss: Bedrock structure template is stored in world/behavior-pack data that is not transferred to a Java datapackfoobar 1 2 3 becomes # unsupported: unknown command foobar (addon/plugin commands are not transferred)spreadplayers 0 0 5 20 @a becomes # unsupported: spreadplayers 0 0 5 20 @a is missing the Java respectTeams boolean before targets (invalid source command)give @p 264 3 becomes # unsupported: items id minecraft:264 is not available in java 26.3 (id is absent from the official java 26.3 registry)A block, item or sound name is never guessed by resemblance. Before writing an identifier into a command, the engine looks it up in Mojang's 7 OFFICIAL registries for the target version: blocks, items, entities, effects, sounds, particles, biomes. An identifier missing from the registry of the version you are going to play is named in your report, not swapped for a neighbour that would look right.
These roots exist in both editions. Five of them (/function, /schedule, /loot, /place, /structure) point at a datapack or behavior-pack file: that file does not travel with the world, so the command is flagged rather than translated into the void. Two more follow the same rule: /recipe on a named recipe, when the two editions do not define a strictly identical one, and /transfer, which identifies a player in an edition-specific way.
Java has none of these. Going Bedrock → Java, each one is named in your report at its exact position.
Bedrock has none of these. Going Java → Bedrock, each one is named in your report at its exact position.
In total, the engine recognises 117 command roots on the Bedrock side and 95 on the Java side. Anything outside those two lists comes from a mod, a plugin or an addon: that content does not cross over, and the command calling it is flagged rather than copied into a world where nothing runs it any more.
What follows is tiny, and none of it is a warning. It is the level of detail we work at: even down there, when something cannot cross over, it is written down.
These states exist in no world file, conversion or not: they are recreated every time you open your game.
These lists come straight out of the engine's own tables, and an automated test breaks the site build if they drift by a single identifier. If something is here, it is converted. The reverse does not follow: a few Java things do not exist in Bedrock (Sweeping Edge, Glowing, Dolphin's Grace…), and they have their own card above.
The goal is not just that your world opens in the other edition.
It is that you find it as you left it.
Terrain, builds, items and world state are translated as far as the two editions allow. When they genuinely differ, we adapt or flag the difference rather than hide it. And if something slipped past us on your world, write to bug@worldswitchapp.com with the position and conversion reference. Only attach the source world if the team asks for it or if you voluntarily choose to do so; it may then be reviewed for diagnosis.
Version of this specification: 7 October 2026. It is part of the contract (Terms, art. 8): a frozen copy is attached to every order confirmation.