How to Upload a Minecraft World to a Server

Before you upload a Minecraft world to a server

This workflow covers Java Edition saves, including singleplayer worlds and existing Java server worlds. A Bedrock save is not a Java save with a different filename; stop and find an edition-specific transfer or conversion procedure instead. If you need help exporting from a particular provider, use our Aternos and Minehut migration guide first.

Record the Minecraft version, server software or mod loader, pack release, and any world-generation mods or datapacks. Recreate that environment at the destination before loading the save. Keep the move separate from a version upgrade: our modpack update workflow covers that different operation.

For singleplayer, open the save folder through the world-edit screen where available, or open the launcher profile's game directory and inspect saves. Use the actual profile directory, not an unrelated default installation. Check a familiar world name and recent save time before copying anything.

Prepare a complete, stopped-world copy

Exit the singleplayer world, or stop the source server normally and wait for shutdown. Make an untouched archive and a separate working copy. Back up the destination too, even if it currently contains only a test world. Do not let an upload overwrite your only recoverable copy.

Find the directory containing level.dat. Preserve the whole save, not just that file or the terrain files. Player data, datapacks, dimension data and mod-specific state matter too. A modded server can also keep persistent information outside the world directory; inventory those files against the pack's instructions.

The provider-authored Aternos upload documentation confirms that a world upload must include its save files and subfolders. Its upload buttons are specific to Aternos; your destination's file manager may instead require extraction or a different transfer method.

• Open the archive locally and confirm that it can be read.
• Note the uncompressed size and allow space for the archive, extracted world and backup.
• Keep a screenshot of a landmark, its coordinates and your inventory for comparison.
• Keep private server configuration out of any archive you share publicly.

Upload and select the correct folder

Stop the destination server. Transfer your working copy using its documented world-import tool, file manager or SFTP access, where provided. A generic file upload usually just stores the ZIP; it does not necessarily extract or activate it. Check the resulting files before starting.

For a conventional Java server directory, the selected world folder should directly contain level.dat. For example, if the folder is named friends-world, the intended path is friends-world/level.dat, not friends-world/My Save/level.dat. An extra archive wrapper is a common reason the server generates an apparently empty replacement.

Set level-name=friends-world in server.properties when using that conventional layout. Match the folder name exactly, including case. Paper's property reference documents this folder selection. If your host manages world selection through a panel, use its documented setting and check whether it rewrites the file.

Do not merge an imported world into an existing generated world. Keep the old destination separately and use a clean target directory. Combining unrelated region files can produce a mixture of two saves that is harder to diagnose than a failed import.

Keep dimension layouts intact

Moving between identical software versions is simpler than changing server families. Directory layouts are version-sensitive. Older Paper layouts can split the Nether and End into sibling world folders, while other layouts keep dimension data under the main save. Copying only the Overworld can leave the destination unable to find existing dimension builds.

Use the Paper migration instructions for your exact source and destination; that page separates historical and newer layouts. Do not apply an old DIM-1 recipe blindly. Likewise, copying a modded world into Paper does not make its custom blocks or mods supported. Preserve the original software combination unless you have a documented conversion plan.

Verify the transfer before inviting players

Start privately and read the startup log. If it reports missing content or an unsupported save, stop rather than forcing it through. Join with the matching client and run this acceptance check:

1. Visit the recorded coordinates and inspect buildings, containers and nearby terrain.
2. Visit previously explored dimensions and check a known landmark in each.
3. Check inventories, ender chests and relevant quest or team progress with their owners.
4. Make a small reversible change, stop normally, restart and confirm it persisted.

Keep the source archive after the first successful login. A world opening at spawn proves much less than a familiar base surviving a restart.

Fix an empty world or missing progress

The server generated a new world

Stop it and check the selected name, folder nesting and extraction result. Do not regenerate repeatedly or change the seed: a seed does not restore your builds. Correct the path using your preserved working copy.

The terrain is right, but player progress is wrong

Check that player-related files were included and that the same accounts and authentication setup are being used. A singleplayer owner's state may need separate handling when moving to a dedicated server. Avoid speculative player-file renaming or disabling authentication; keep the original and request version-specific guidance.

Choosing a destination next? Compare Minecraft hosting options against your save's exact software requirements, and confirm the import process before moving it. The checkpoints here are conservative operational recommendations; linked primary documentation was reviewed October 13, 2026.