Chunker moves Minecraft worlds between Java and Bedrock, including across game versions

Two editions, two save formats, one converter

Chunker is a Java application that converts Java and Bedrock Minecraft worlds, with a simple interface, and it also upgrades and downgrades worlds between different versions of the game. That second capability is the one most people do not expect, because the usual framing of this problem is edition conversion alone.

The distinction matters in practice. A world created in an older Java release and a world created in a recent Bedrock release are different problems from a Java world and a Bedrock world, and the version list in the README shows the project treating both as first class. The supported Bedrock versions run from 1.12.0 through 1.26.60, and the Java versions from 1.8.8 up through 1.21.11 and 26.1 to 26.3.

The project is maintained by Hive Games, the company behind The Hive Minecraft server, and the README states that the project receives funding from Mojang Studios while Mojang Studios and its parent company Microsoft assume no responsibility for its contents. The homepage is chunker.app, and the README also links a Microsoft Creator documentation page giving an overview of Chunker.

For a server operator the practical value is straightforward: you can move a world to the other edition without asking every player to start again, and you can pull a world forward when the game updates rather than leaving it behind.

The supported version list is the real specification

The README lists the supported formats in detail, and that list is the contract you should check before anything else.

For Bedrock there are ten entries: 1.12.0, 1.13.0, 1.14.0 to 1.14.60, 1.16.0 to 1.16.220, 1.17.0 to 1.17.40, 1.18.0 to 1.18.30, 1.19.0 to 1.19.80, 1.20.0 to 1.20.80, 1.21.0 to 1.21.130, and 1.26.0 to 1.26.60. For Java there are fifteen: 1.8.8, 1.9.0 to 1.9.3, 1.10.0 to 1.10.2, 1.11.0 to 1.11.2, 1.12.0 to 1.12.2, 1.13.0 to 1.13.2, 1.14.0 to 1.14.4, 1.15.0 to 1.15.2, 1.16.0 to 1.16.5, 1.17.0 to 1.17.1, 1.18.0 to 1.18.2, 1.19.0 to 1.19.4, 1.20.0 to 1.20.6, 1.21.0 to 1.21.11, and 26.1 to 26.3.

The pattern is that a version line appears as a base number and a patch ceiling, which is how the editions actually number their releases. A world from a Java 1.21.11 build converts to a target in the 1.21.0 to 1.21.11 range, and the tool will not accept a target it does not know.

That last point has a practical consequence. The command line can list what is available, and the README gives a deliberately odd way to do it: give the tool an incorrect input and it prints the formats it knows.

java -jar chunker-VERSION.jar -f ?

So before planning a conversion, run that and read the list, rather than guessing at the version string format from memory.

Three required parameters and a pile of optional ones

Chunker runs either as an Electron application or as a command line application, and the CLI form is the one to script. The requirement is Java 17 or higher, and pre-built copies are published in the releases section.

The minimal invocation takes three parameters.

java -jar chunker-cli-VERSION.jar -i "my_world" -f BEDROCK_1_20_80 -o output

The input directory is -i or --inputDirectory, the output directory is -o or --outputDirectory, and the output format is -f or --outputFormat, written in the form EDITION_X_Y_Z, for example JAVA_1_20_5, JAVA_1_20 or BEDROCK_1_19_30, plus the special value INPUT, which matches the input version.

The optional parameters are where the real control lives, and they are all JSON in or JSON out. -m or --blockMappings takes a path to a json file or a json object with block mappings, -s or --worldSettings takes world settings, -p or --pruning takes pruning settings, and -c or --converterSettings takes converter settings. Two more handle the parts of a world that are not just blocks: -r or --dimensionRegistry takes custom dimension definitions, and -d or --dimensionMappings takes dimension mappings, with -b or --biomeMappings doing the same for biomes.

One flag is a genuine trap. -k or --keepOriginalNBT indicates that NBT should be copied from the input to output where Chunker processed it, but the README states this is only supported where the output format is the same as the input, and that for optimal results you want to copy the input world to the output folder prior to conversion.

There is a pleasant workflow detail here too. You can export the settings for a world using the web interface on chunker.app through the Advanced Settings and Converter Settings tab, and the CLI also supports preloading settings from the input directory, so the settings you tuned in the browser can travel with the command.

The app and the cli are separate build artifacts

The repository is a Gradle project with two modules, app and cli, and the README is explicit about the split. The app provides an Electron frontend for the application, and the cli is a pure Java application that can be used for conversion or for integrating conversion.

That separation is a practical advantage for anyone automating conversions. A server operator can run the jar on a machine with no display and no Electron, and a map maker can use the desktop application for the interactive side of setting up a world.

The build steps are listed as three commands. Clone the repository, build the project, and take the binary from build/libs/, where you get it either as a CLI jar, a native CLI executable, or with the Electron frontend.

git clone git://github.com/HiveGamesOSS/Chunker.git
./gradlew build

The requirements are Git, Java 17 or higher, and optionally Gradle, since the wrapper is included in the repository.

Memory is the one runtime setting that matters for large worlds. Chunker defaults to a maximum of 75% of available memory, and you can customise it by specifying the amount when launching, for example Chunker.exe -Xmx8G for 8 gigabytes. Chunker forwards -Xmx and -Xms to the backing JVM, and if you want to supply other options you use --java-options="...".

One implementation detail is worth knowing if you are debugging conversions of Bedrock worlds. Chunker uses its own fork of a Java LevelDB implementation, leveldb-mcpe-java, which is where the Bedrock level format is actually read.

Block identifiers are checked against the edition palettes in the build

The Testing section describes an approach that is unusual for a converter tool, and it is the strongest evidence in the README that this is a maintained engineering project rather than a script.

Chunker attempts to do automated testing where possible to validate data. The example given is that block identifiers are validated against the palette of the Bedrock and Java editions, and that this allows issues with faulty mappings to be identified in the build process. In other words, a mapping table that is wrong for a version is caught by a test rather than by a player noticing a missing block in their world.

The tests can be skipped in the build process by appending -x test to the./gradlew build command. Some tests are excluded from the default suite and marked with the LongRunning tag, because they can take several minutes to fully complete.

The validation story connects back to the version list. A converter that supports fifteen Java versions and ten Bedrock versions has a large matrix of block identifiers to keep correct, and the palette check is how that matrix is policed. It is also why the mapping flags exist: when the palette check flags a specific block, the fix is a mapping override rather than a code change.

For a user, the practical benefit is that a successful conversion is more likely to be a complete one, and for a developer, the palette check is the place to add a case when a new game version lands.

Entities and structures do not come across, and that is the deal breaker

The README has a section headed Currently unsupported features, and it is short enough to quote. The following features do not convert, or have limited conversion, when using Chunker: entities, excluding paintings and item frames, and structure data, for example villages and strongholds.

That is the honest boundary of the tool, and it is a real one. Entities include mobs, item entities, villagers and the logic attached to them, and structure data includes the generated content of a village or a stronghold, which is stored separately from the ordinary blocks and entities in the world save. A converted world keeps the terrain, the buildings you built and the blocks you placed, and loses the inhabitants and the generated structures.

For a creative map or a survival world that someone has built by hand, that is usually acceptable. For a world where a village with its trade halls and a working farm is the point, it is not, and no setting in the CLI changes it.

The legal and funding position is also stated. The project is MIT licensed, with details in the LICENSE file, and the repository carries a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, a SECURITY.md and a SUPPORT.md alongside the code. The release history shows 1.21.0 on 2026-10-02, 1.20.0 on 2026-09-02 and 1.19.1 on 2026-08-03, and the last push was on 2026-10-16, so the tool tracks new game versions closely.

Editorial conclusion

Chunker fits a server operator or map maker who has worlds in the other edition, or who wants to move a world across Minecraft versions without rebuilding it from scratch, and who can accept losing entities and villages. It is the wrong tool for a world whose mobs or generated structures matter, because those are exactly what it does not carry over. Verify first that your exact source and target versions are in the supported list, and keep a copy of the input world, since the keepOriginalNBT option only applies when the output format matches the input format.

Frequently asked questions

Official sources

1. HiveGamesOSS/Chunker on GitHub
2. License: MIT
3. Project website
4. README
5. Releases