Export formats

A country-sized world can be tens of gigabytes. Meld’s Export drawer offers five ways to package the result, from “leave it alone” to server-only formats that genuinely shrink it several times over. This page says what each one is for, and what compression can and cannot do to a Minecraft world.

Why compression is harder than it looks

A vanilla world is Anvil format: .mca region files whose chunks are already compressed (zlib) by design. Compressing compressed data barely works, which is why zipping a world gives an unimpressive ratio no matter which archiver you use; Meld measured zip, tar.zst and friends all landing near the same ~1.85x. That is the ceiling for anything that keeps the Anvil bytes intact.

Breaking the ceiling requires changing the storage itself: decompress every chunk, strip the per-chunk overhead, and recompress the raw data as one modern zstd stream per region. That is what the Linear family does, and it is why it reaches ~4.85x at level 9, but also why only servers that speak the format can read it.

The formats

• Raw Anvil (default). No export step at all. The merged world is a working vanilla single-player world; copy it into your saves and play. Compression is always opt-in, an untouched build never needs unpacking.
• Zip / tar.zst. Universal archives at ~1.85x, for storage and transfer. They extract back to the vanilla world; nothing about the world changes.
• Linear. Per-region .linear files for Leaf and Folia servers, ~4.85x smaller at level 9. Write it next to the .mca or as a separate <name> [Linear] sibling world, with the original untouched. An optional stream-and-free mode keeps peak disk usage near the compressed size, and overlap mode starts compressing while generation is still running.
• B_Linear. Builds a <name> [BLinear] sibling world for Leaf’s B_LINEAR format, through a bundled cross-platform Rust converter (based on LuminolMC’s region_converter, MIT). Keep-modes decide what survives after the new world verifies: keep both (default), B_Linear only, or archive the .mca as a zip first. The .mca is only ever removed after everything verifies.

Verified against the real server

Meld’s B_Linear output was verified byte-identical to Leaf’s own bucketed v3 layout (same superblock, version byte, header fields and hash seed, checked against the Leaf binary itself), and its classic Linear v1 files load under Leaf’s reader, which accepts v1 through v3. A Leaf server later rewrites .linear regions as version 3; the bundled meldconvert.py CLI detects that and routes the conversion back through the Rust converter, so a server-run world still converts cleanly to .mca. The same CLI does any direction, mca <-> linear <-> blinear, plus an info inspector.

Cost and workers

Export runs after the merge, parallelised across your CPU: compression workers default to your logical cores minus one (reserving a thread for the app, once you have at least 4 cores), and the worker count is settable if you want the machine quieter. The Export drawer shows an estimated output size that updates with the chosen format, and the render queue uses the same estimate for its combined total.

How to choose

• Playing single-player? Raw. There is nothing to gain from an export you immediately unpack.
• Archiving or sending a world? Zip or tar.zst, and accept ~1.85x; that is what archiving already-compressed Anvil data gets.
• Running a Leaf/Folia server? Linear or B_Linear, picked in the Export drawer before generating or applied to a finished world. The one-click server stages whichever files you chose and always writes a matching region-format config, so a Linear world can never be served as MCA by mistake.

If an estimate ever reads low or an export seems stuck, the troubleshooting guide covers the usual causes. And remember the sibling-world design means every conversion is reversible until you explicitly discard the original: Meld deletes nothing it cannot verify a replacement for.