To enable a datapack in Minecraft Java Edition, put the pack (a .zip or a folder with pack.mcmeta at its top) into the world's datapacks folder and load the world. On a new singleplayer world you can do it from the Create New World screen: More, then Data Packs, then move the pack from Available to Selected. On an existing world or a server, drop the file into world/datapacks/ and run /reload, or enable it by name with /datapack enable "file/<name>". New packs found in that folder are switched on automatically unless something has marked them disabled, and most of this post is about the cases where that happens.
Datapacks are a Java Edition feature. Bedrock has no datapacks; its equivalent is behaviour packs, which are installed and enabled through a completely different route.
The quick answer, by situation#
There are four places a pack can be enabled, and they do not share a screen or a command:
| Where you play | How to enable | Takes effect |
|---|---|---|
| New singleplayer world | Create New World, More, Data Packs | When the world is created |
| Existing singleplayer world | World folder, datapacks, reload | On next load or /reload |
| Dedicated server | world/datapacks/, then /datapack enable | Immediately |
| Realm | Upload a world that already has the pack | After the upload |
Two commands do almost all the work once you are in a world or a server console:
$ datapack list$ datapack enable "file/house-rules.zip"The rest of this post goes through each route step by step, then covers the things that make a pack show up as disabled: experimental feature packs, pack_format warnings, safe mode and the server's own start-up settings. Installing, ordering, writing and debugging packs in depth is in the Minecraft datapacks guide, and none of that is repeated here.
Singleplayer: enabling packs when you create a world#
The Create New World screen is the only place in the game with a proper interface for datapacks, and it only exists before the world does.
- From the title screen choose Singleplayer, then Create New World.
- Open the More tab and click Data Packs. On versions before the tabbed screen arrived (around 1.19.4), Data Packs is a button directly on the create screen.
- Click Open Pack Folder. A file browser opens on a temporary folder. Copy your
.zipfiles or pack folders into it. On current versions you can also drag a zip straight onto the game window and confirm the copy. - Back in the game the pack appears in the Available column on the left. Hover over it and click the arrow to move it into Selected on the right.
- Click Done, set the rest of the world up as usual, and create it.
The game copies every selected pack into the new world's own datapacks folder, so the world carries its packs with it from then on. Order in the Selected column matters when two packs change the same file: packs higher in the list override those below them, and the built-in vanilla data always sits at the bottom.
If a pack does not appear in Available at all, the game could not read it as a pack. The usual reason is a zip with a wrapper folder inside it, so pack.mcmeta is one level too deep. That and the other structural problems are covered in the datapacks guide.
Singleplayer: adding a pack to a world you already have#
There is no Data Packs button for an existing world. You add the file by hand:
- From Singleplayer, select the world, click Edit, then Open World Folder. The folder for that save opens in your file browser.
- Open the
datapacksfolder inside it. Create it if it is missing; the name is exactlydatapacks, lowercase, no space. - Copy the pack in, either as the zip or as the unpacked folder.
- Load the world.
On Windows the saves live in %APPDATA%\.minecraft\saves\<world name>\, if you would rather go there directly. The world folder name is not always the same as the name shown in the menu, which is why the Edit route is safer.
When the world loads, the game compares the packs in the folder with the lists stored in level.dat. A pack it has never seen before is enabled automatically. That is the whole procedure for most people: copy, load, done.
If the world is already open, you do not need to quit. Run /reload and the game rescans the folder, enables any new packs and reloads everything. Running a command needs cheats, so on a world created without them you can open it to LAN with Allow Commands on, which grants them for that session only. Check the result:
$ /datapack list enabledThe pack should appear as file/<name>. If it appears only under /datapack list available, the game found it but something is holding it disabled, and the section on that below is where to go next.
Dedicated servers: the folder, the commands and reloading#
A server reads packs from one place: the datapacks folder inside the main world directory, whose name comes from level-name in server.properties (world by default). On Paper the nether and the end are separate folders, but packs placed in world_nether or world_the_end are ignored; only the main world's folder counts.
Upload the pack, then either restart the server or reload it from the console. On a running server the sequence looks like this:
$ minecraft:reload$ datapack list$ datapack enable "file/vt-graves.zip"A few rules that save time:
- The name is
file/followed by the file or folder name exactly as it appears on disk, including.zipwhen it is a zip. Quote it, because of the slash. /datapack enableand/datapack disabletrigger a reload by themselves. You do not need to run/reloadafterwards./reloadon its own also picks up new packs and enables them, as long as they are not on the disabled list.- On Paper, Spigot and their forks, plain
/reloadis Bukkit's plugin reload, which is unsafe on a live server. Useminecraft:reload, which is the vanilla datapack reload. - From the console you type commands without the leading slash. In game they need it, and they need operator level 2.
The full command set:
| Command | What it does |
|---|---|
datapack list | Shows enabled and available packs |
datapack list available | Only packs found but not enabled |
datapack list enabled | Only packs currently on |
datapack enable "file/x" | Turns a pack on, placed last by default |
datapack enable "file/x" first | Turns it on with lowest priority |
datapack enable "file/x" before "file/y" | Places it relative to another pack |
datapack disable "file/x" | Turns a pack off and reloads |
Positions matter only when two packs replace the same file. The datapacks guide explains how the order decides which one wins.
Disabling a pack does not delete it. The file stays in the folder and the pack is added to the disabled list in level.dat, which is why it will not come back on its own after a restart. To remove it for good, disable it, stop the server and delete the file. Disabling a pack that added recipes, loot or functions is harmless; disabling one that added dimensions or biomes to a world that used them is not, so take a backup first.
On RE:NODE, Minecraft servers run Paper with the world already generated, so world/datapacks/ exists the first time you open the file manager. Packs go in through the browser or over SFTP (see SFTP and the file manager), and the panel console takes minecraft:reload and datapack commands directly, with history and tab completion.
initial-enabled-packs and initial-disabled-packs#
Since 1.19.3, server.properties has two keys that decide which packs a brand new world starts with:
initial-enabled-packs=vanillainitial-disabled-packs=Both take comma-separated pack names. They apply once, when the server generates the world, and are ignored for a world that already exists. That trips people up: adding a pack name to initial-enabled-packs and restarting an existing server changes nothing at all.
They are useful in two situations. The first is turning on experimental feature packs on a dedicated server, which has no create-world screen; that is covered in the next section. The second is keeping a pack off from the start. If you preload a datapacks folder before the first launch, every pack in it is enabled when the world generates; listing one in initial-disabled-packs keeps it in the folder but switched off until somebody enables it.
initial-enabled-packs=vanilla,trade_rebalanceinitial-disabled-packs=file/test-packThe rest of the file, key by key, is in server.properties explained.
Experimental packs: the Experiments screen and feature flags#
Mojang ships upcoming features as built-in packs that are off by default. Turning one on changes world generation or game mechanics, so the game treats them differently from ordinary packs: they set feature flags on the world, and feature flags can only be set when the world is created.
Which experimental packs exist depends entirely on the version. Each one is added for a preview and removed once its feature ships in a normal release. As examples: around 1.19.3 and 1.19.4 there were update_1_20 and bundle; 1.20.5 shipped update_1_21; trade_rebalance has been present for several releases; 1.21.2 added minecart_improvements and redstone_experiments. Names from an older guide may simply not exist on your version, so check rather than copy.
To see the ones your version actually has:
- In singleplayer, Create New World, More, then Experiments. Each toggle there is one experimental pack. On older versions they appear in the Data Packs screen instead, marked as experimental.
- On a server, run
datapack listand look for built-in names other thanvanillaandfile/...entries. The release notes for your version are the authoritative list.
On a dedicated server, the only clean way to enable one is initial-enabled-packs before the world exists:
- Stop the server.
- Move or delete the existing world folder (keep a copy if you want it).
- Set
initial-enabled-packs=vanilla,<experiment name>inserver.properties. - Start the server so it generates a new world with that flag set.
Running datapack enable on an experimental pack in an existing world fails with a message that the required feature flags are not enabled in this world. That is not a bug; it is the game refusing to bolt experimental blocks and mechanics onto a world that was not generated for them.
pack_format warnings and incompatible packs#
Every pack declares a pack_format in its pack.mcmeta, a number that tracks the data format of one Minecraft version or a range of them. When the number does not match what your game expects, the pack is flagged as incompatible.
In singleplayer the Data Packs screen shows the pack in red with a note that it was made for an older or a newer version of Minecraft. You can still select it; the game asks you to confirm. In the server console there is no prompt, and the pack loads anyway.
Whether an incompatible pack works is a separate question from whether it loads. A mismatched number with files in the right layout often works perfectly. A matching number with files in the old layout does nothing. The common case is a pack built for 1.20 on a 1.21 server: it enables cleanly, /datapack list shows it, and it has no effect, because 1.21 renamed the folders inside packs from plural to singular. The table of format numbers and the folder rename are both in the datapacks guide.
The practical rule: download the build of the pack made for your exact Minecraft version. Ready-made packs such as Vanilla Tweaks ask for the version before you download for this reason. Only edit pack_format yourself when you know the files inside are already in the right shape.
Why a datapack shows as disabled#
datapack list separates enabled packs from available ones. A pack that is in the folder but stuck under available has one of these causes, in roughly this order of likelihood:
- Someone disabled it earlier.
/datapack disable, or deselecting it in a Data Packs screen, records it in the disabled list inlevel.dat. Packs on that list are not re-enabled by a reload or a restart. Enable it by name. - It needs a feature flag the world lacks. An experimental pack, or a third-party pack that declares it needs one, cannot be enabled on a world created without that experiment.
- It was listed in `initial-disabled-packs` when the world was generated, which put it on the disabled list from the first tick.
- The world was opened in safe mode. When a pack fails to load badly enough, singleplayer offers to open the world in safe mode with only vanilla data, and a dedicated server refuses to start and suggests the
--safeModelaunch flag. Both load without your packs; once the faulty pack is fixed or removed, enable the others again and check the list. - The pack failed to load. A broken JSON file or a bad function does not always disable the whole pack, but the console prints an error naming the file at load or reload. Read the log before changing anything else.
And if the pack is not in either list, the server never found it: wrong folder (a nether folder, or a world folder that level-name does not point at), a zip with a wrapper folder, or a file name that is really pack.zip.zip because Windows hides extensions.
A small but frequent mistake belongs here too: datapack enable "file/graves" fails with an unknown pack error when the file on disk is graves.zip. Copy the exact name from datapack list available; tab completion in the console fills it in correctly.
Realms, LAN worlds and servers are not the same#
Realms is Mojang's hosted service, and on Java Edition it gives you no file access. There is no datapacks folder to upload into and no console. The route is indirect:
- Build the world in singleplayer with the packs you want, enabled and working.
- In the Realm's configuration, use the option to upload a world, and pick that save.
- The upload replaces the world in that Realm slot, packs included.
After that, /datapack commands work for an operator in the Realm, so you can disable or reorder packs already there. Adding a new pack later means repeating the upload, which replaces the Realm's world with your local copy. Download the Realm's world first, add the pack locally, and upload that, or you will roll back everything players did since your last copy. Bedrock Realms do not take datapacks at all; they use add-ons.
A LAN world is just your singleplayer world opened to other players, so its packs are managed exactly as in the singleplayer sections above, on your machine.
A dedicated server is the only one of the three where you control the files directly, can see the log, and can enable or remove packs while people are playing. If a group has outgrown uploading worlds back and forth, that is usually why. Moving a singleplayer world with its packs onto a server is the same as moving any world: upload the world folder, datapacks included, and point level-name at it. Minecraft world backup and restore covers moving and restoring worlds safely.
FAQ#
Do I need to restart the server after adding a datapack?
No. Upload it and run minecraft:reload from the console, or enable it by name with datapack enable, which reloads by itself. A restart also works and is the safer option if the pack adds world generation.
Why does /datapack enable say the pack does not exist?
The name is wrong. It must be file/ plus the exact file or folder name, including .zip, in quotes. Run datapack list available and copy it from there.
Can I turn on experimental features in a world I already have?
Not through the game. Experimental packs set feature flags that are fixed at world creation. Create a new world with the experiment selected, or on a server set initial-enabled-packs and let it generate a fresh world.
Does every player need the datapack installed?
No. Datapacks run on the server, or on the host's machine for a LAN world. Players only need a resource pack if the datapack uses custom textures or models, and that is a separate file.
Do datapacks work on Bedrock Edition?
No. Datapacks are Java only. Bedrock uses behaviour packs, and a Java datapack cannot be converted by renaming files.
Will enabling a datapack change my existing world?
Recipes, loot, advancements and functions apply as soon as the pack loads. World generation packs only affect chunks generated after they were enabled, so explored areas stay as they were and new terrain may not join neatly at the edge.


