Publishing and Sharing Your Work - Minecraft Data Packs: A Complete Guide

Part XII — Finishing and Sharing. The final chapter.

What You’ll Build

In this chapter you don’t build a new feature. Instead you get the pack you’ve been building since Chapter 9 ready to hand to other people. You’ll write a clear description (the blurb that shows next to your pack in-game), add a pack.png icon, tidy your folders so a stranger can read them, make sure your pack plays nicely alongside other people’s packs, package it as a .zip, and learn where people share data packs. You’ll also meet two ideas that will serve you far beyond Minecraft: licensing (telling people how they’re allowed to use your work) and version control with Git (keeping a safe history of every change). By the end you’ll have a finished, shareable pack, and you’ll have finished the book.

This is mostly about polish and good habits, not new mechanics. Some of it (the sharing websites, licensing, Git) is ordinary real-world advice that isn’t part of Minecraft itself. It’s marked as general guidance where it appears.

Concepts

A pack is just a folder or a `.zip`

You’ve known this since Chapter 7, but it matters now: a data pack is either a folder or a .zip file containing a pack.mcmeta file. That’s the whole definition. The pack.mcmeta (the small marker file you wrote in Chapter 9) is what makes a plain folder count as a real pack: it is the only mandatory file. Everything else (your functions, recipes, loot tables) is optional from the game’s point of view.

That single fact is why sharing is easy. To give your pack to a friend, you hand them the folder (or, better, a .zip of it) and they drop it into their world’s datapacks folder, exactly the way you’ve been loading your own pack all along.

Modern Minecraft — Older guides sometimes talk about “installing” a data pack as if it were a complicated program. It isn’t. A data pack is data, not a program: it’s a folder of text files the game reads. “Installing” it just means putting that folder (or .zip) where the game looks for it.

The description: the blurb players read

Your pack.mcmeta already has a description field. The game shows that description as a text component (the styled-text format from Chapter 5) that appears when you hover over the pack’s name in the pack list, and when you view the pack in the Create World screen. So it’s the first thing anyone sees about your pack.

Up to now your description has probably been something plain like "My first data pack". For a pack you’re sharing, make it do a job: say what the pack does in one short line. Because it’s a text component, you can give it color and style, just like the messages you styled in Chapter 5.

Here’s the pack.mcmeta for the pack you started in Chapter 9, with a share-ready description:

mypack/pack.mcmeta

{
  "pack": {
    "description": [
      { "text": "Sunforged", "color": "gold", "bold": true },
      { "text": " — custom drops, recipes & more", "color": "white" }
    ],
    "min_format": 107,
    "max_format": 107
  }
}

Two things to notice. First, the description is an array of text-component pieces (exactly the list form you learned in Chapter 5), so part of it is gold and bold and part is plain white. A single plain string (like "description": "My first data pack") is still perfectly valid; the array just lets you add color. Second, min_format and max_format are the version fields from Chapter 9 and Chapter 46: they tell the game which Minecraft versions your pack is built for. Leave them set the way Chapter 46 taught.

Try It! Write three different one-line descriptions for your pack, then read each one out loud. Pick the one that would make you click “download” if you saw it in a list of fifty packs. Short and specific beats long and vague.

The icon: `pack.png`

Right next to the pack.mcmeta, in the same top-level folder, you can put a file named pack.png. This is the picture displayed next to the data pack in the “Data Pack Selection” screen. (Resource packs work the same way: a pack.png shows next to them in the “Select Resource Packs” screen.) It’s optional (your pack works fine without one), but a pack with an icon looks finished, and on sharing sites a good icon is what makes someone stop scrolling.

So the very top of your pack now looks like this:

mypack/
  pack.mcmeta      ← the marker file (required)
  pack.png         ← your icon (optional)
  data/
    mypack/
      function/
      recipe/
      loot_table/
      ...

You know where pack.png goes and what it’s for. The image’s size and shape are up to you, with one piece of plain guidance: the in-game pack icons are shown as small squares, so a square image reads best. Make it square, keep it simple, and you’re set.

Try It! Make a simple square icon for your pack in any image editor — even a single bold symbol on a solid background works. Save it as pack.png in your pack’s top folder, reload, and open the Data Packs screen to see it appear.

Organizing files so a human can read them

The game doesn’t care how tidy your folders are; it finds files by their path, not by how neatly they’re arranged. Recall the rule from Chapter 9 and Chapter 14: a file at data/<namespace>/<registry name>/<path>.json is loaded into that registry with the ID <namespace>:<path>, and both the registry name and the path can contain slashes, which makes extra sub-folders. That last part is your tidiness tool.

Because the path can contain slashes, you can group related files into sub-folders without breaking anything. Compare a flat pile of loot tables:

data/mypack/loot_table/husk.json
data/mypack/loot_table/zombie.json
data/mypack/loot_table/mystic_ore.json
data/mypack/loot_table/treasure_chest.json

…with the same files grouped by what they’re for:

data/mypack/loot_table/entities/husk.json
data/mypack/loot_table/entities/zombie.json
data/mypack/loot_table/blocks/mystic_ore.json
data/mypack/loot_table/chests/treasure_chest.json

Both work. The second one tells a reader (including future-you) at a glance which tables are mob drops, which are block drops, and which are chests. The only thing to remember is that moving a file changes its ID: mypack:husk becomes mypack:entities/husk, so any function or table that referenced the old ID has to be updated. (This is the same path-equals-ID rule you’ve used since Chapter 9, nothing new, just applied on purpose.)

A few plain-sense habits make a shared pack pleasant to read:

Use clear file and function names. husk_reward tells a reader more than func3.
Comment your functions. A # line at the top of an .mcfunction (Chapter 9) saying what it does costs nothing and saves a reader minutes.
Keep one namespace, and make it yours. Everything you’ve built lives under mypack. When you share for real, swap that for a namespace that’s clearly yours. That leads straight to the next idea.

Compatibility: don’t step on other packs

Here’s a problem you’ve been protected from all book long, because you’ve only run your own pack. The moment someone runs your pack alongside somebody else’s, files can collide. The rule for how collisions resolve is blunt: if a file exists in multiple data packs, only the file in the last data pack is used. This is called overriding the earlier file.

So if your pack and another pack both contain a file at exactly data/minecraft/loot_table/entities/zombie.json, whichever pack loads later wins and the other one’s version is silently ignored. Two well-meaning packs can break each other without either author doing anything “wrong.”

The fix is the idea you met in Chapter 8 and have used on every file since: namespaces. Data is organized into namespaces specifically to avoid files from different packs unintentionally interfering with each other. A file at data/mypack/... and a file at data/coolpack/... can never collide, because their paths differ. So the single most important compatibility rule is:

Keep all of your own content under your own unique namespace. Don’t reuse mypack if you publish; that’s the book’s teaching name and other learners use it too. Pick something distinctive (your username, your project’s name) in the lowercase-underscore style from Chapter 8, and put everything there.

There’s one place you can’t avoid sharing a path with everyone else, and it’s worth knowing. When you intentionally change a vanilla thing (like the zombie-drops override from the projects in Part IX) you must use the minecraft namespace, because that’s where vanilla’s own files live. Two packs that both override data/minecraft/loot_table/entities/zombie.json will clash, and only the later one survives. There’s no perfect cure, but you can reduce the damage:

Prefer adding over replacing. Tags are the friendly exception: tag files without "replace": true merge their content with the files loaded from earlier packs. So if you add your function to minecraft:tick (Chapter 14) without "replace": true, your entry joins everyone else’s instead of wiping them out. Whenever you can express an addition as a tag, you avoid the override fight entirely.
Mention what you override. If your pack must replace a vanilla file, say so in your description or notes, so someone combining packs knows where a conflict could come from.

Under the Hood (skippable) — Which pack counts as “last”? Data packs load in a load order that you can see and change on the Data Packs screen and with the /datapack command, and that this order is stored in the world’s level.dat file. Packs lower in the list load first; packs above them load later and therefore win ties. This is the same load-order idea behind tag merging and file overriding: it’s all one system.

Packaging: zipping your pack

To share a pack as a single file, turn the folder into a .zip. Remember the definition: a data pack is a folder or a .zip containing a pack.mcmeta. The one thing that trips everyone up is what’s at the top of the zip.

The pack.mcmeta (and pack.png, and the data/ folder) must sit at the root of the zip, not inside an extra wrapper folder. In other words, when you open the zip you should immediately see pack.mcmeta, not a folder you have to click into first. If you zip the containing folder by mistake, the game opens the zip, sees a folder instead of pack.mcmeta, and doesn’t recognize it as a pack.

What Went Wrong? “I zipped my pack and the game won’t list it.” Almost always this is the wrapper-folder mistake. Open the .zip and check: do you see pack.mcmeta right away? If instead you see a single folder named after your pack, you zipped one level too high. Go into the pack folder, select pack.mcmeta + pack.png + data/ together, and zip those.

Under the Hood (skippable) — A resource pack zips the same way, with pack.mcmeta at the root. The book’s resource-pack chapters (Part VIII) even used a special case of this: a resource pack zipped and renamed resources.zip, dropped into a world folder, rides along with that world. Same packaging idea, different destination.

Once your pack is a tidy .zip with a good description and icon, you can put it where people look for data packs. The big community sites are:

Modrinth — a modern, open hosting site for Minecraft content (mods, resource packs, and data packs). Clean, free, and creator-friendly.
Planet Minecraft (PMC) — a long-running community site with a large audience for data packs, maps, and skins; strong for getting comments and feedback.
CurseForge — one of the oldest and largest Minecraft content hubs, widely used by launchers and modpacks.

These are real-world websites, not part of Minecraft, so the exact upload steps and rules live on each site and change over time. Check their own “how to upload” help pages. Whichever you pick, the same things make a listing good: a clear title, the one-line description you already wrote, your pack.png (or a nicer banner), a screenshot or two of your pack in action (the screenshots this book kept asking you to take), and a short list of what the pack does and which Minecraft version it needs (your min_format/max_format from Chapter 46 tells you that version).

Try It! Before uploading anywhere, write a tiny README, a plain text file that lists what your pack does, how to install it (drop the folder/zip in the world’s datapacks folder, run /reload), and which Minecraft version it targets. You’ll paste most of it straight into the upload form.

Licensing: telling people what they may do (general guidance)

When you publish something you made, other people will naturally wonder: Can I use this? Can I change it? Can I put it in my own pack? A license is a short statement that answers those questions in advance, so nobody has to guess or ask.

This is general creative-work advice, not a Minecraft feature, so keep it simple:

If you say nothing, people are left unsure, and cautious people won’t reuse or build on your work at all. Silence usually reads as “ask first,” which most people won’t.
If you want people to freely use and remix your pack, pick a well-known permissive license (the Creative Commons family is popular for content like this) and include its text or a link, plus a line asking for credit if that matters to you.
If you want to keep tighter control, say what is allowed in plain words: for example, “you may use this in your own maps but please credit me and don’t re-upload it as your own.”

The point is just to add a short, friendly note (often a LICENSE or README file beside your pack) so the people who admire your work know how they’re welcome to use it. When you build on other people’s packs, return the favor: check their license, and give credit.

A first look at version control with Git (general guidance)

Here’s the last new idea in the book, and it’s a gift to your future self.

You’ve felt the pain already: you change a working function, it breaks, and you can’t quite remember what it looked like before. Version control is a tool that fixes exactly that. It keeps a complete history of your project, so you can see every change you’ve made and rewind to any earlier version whenever you want. Git is the most widely used version-control tool, and it works beautifully on a data pack, because a data pack is just a folder of text files, precisely the kind of thing Git is built to track.

This is general programming knowledge, not a Minecraft feature, so here’s just enough to get the idea:

You initialize a Git “repository” in your pack folder once. From then on, Git watches that folder.
As you work, you take snapshots called commits. Each commit saves the exact state of every file with a short message like "add Sunforged Blade recipe" or "fix husk loot chance".
If a change goes wrong, you can look back through your commits and restore an earlier one. Your history is a safety net: nothing good is ever truly lost.
You can push your repository to a site like GitHub or GitLab to back it up online and let others see (and suggest improvements to) your code.

Think of it as /reload for your project’s whole history: instead of just reloading the current files, you can jump to how they looked yesterday, last week, or right before everything broke. You don’t need it to make a great pack, but the day you accidentally delete two hours of work, you’ll be very glad you took the snapshot.

Try It! If you’re curious, install Git and run its “init” and “commit” steps in your pack folder, then make a small change and commit again. Look at the history. Even on a tiny pack, seeing your own change-log appear is a small revelation, and it’s a skill that carries straight into real software work.

Walkthrough: getting `mypack` ready to ship

Let’s turn the pack you’ve built across this whole book into something you could hand to a stranger. Nothing here changes how the pack behaves; it’s all finishing.

1. Write a real description. Open your pack.mcmeta and replace the plain description with a styled one-liner that says what the pack does. Use the array form so you can add color:

mypack/pack.mcmeta

{
  "pack": {
    "description": [
      { "text": "Sunforged", "color": "gold", "bold": true },
      { "text": " — custom mob drops, recipes, and a mystic ore", "color": "white" }
    ],
    "min_format": 107,
    "max_format": 107
  }
}

2. Add an icon. Make a square image, save it as pack.png, and drop it in the top folder right next to pack.mcmeta.

3. Tidy the folders. Group your loot tables into entities/, blocks/, and chests/ sub-folders as shown earlier, and remember to update any IDs that moved. Add a one-line # comment to the top of each function saying what it does.

4. Rename your namespace (when publishing for real). Everything under data/mypack/ becomes data/<your-name>/, and every mypack:... reference updates to match. The book keeps mypack so all chapters line up, but a published pack should wear a namespace that’s clearly yours.

5. Reload and test. Run /reload and confirm everything still works after the moves and renames. This is exactly the “change one thing, reload, check” habit from Chapter 10. Tidying is a great way to accidentally break a path, so test.

6. Zip it. Go into the pack folder, select pack.mcmeta, pack.png, and data/ together, and compress those into a .zip (so pack.mcmeta is at the zip’s root). That single file is your shareable pack.

7. Write a README and pick a license. A short text file with what-it-does, how-to-install, version, and a line about how people may use it. Now you’re ready to upload to Modrinth, Planet Minecraft, or CurseForge.

Figure (to be captured). the Data Packs selection screen showing the finished mypack with its new gold/white description on hover and its pack.png icon beside the name

Practice

Three descriptions, one winner. Write three different pack.mcmeta descriptions for your pack (one plain, one colorful, one funny), load each, and hover to compare them in the list. Keep the one that best tells a stranger what the pack is in a single glance.
Make and test a conflict. Copy your pack folder, rename the copy’s folder, and keep both namespaces the same on purpose. Load both, reload, and watch the override behavior in action: the later pack’s same-path files win. Then fix it by giving the copy its own namespace and confirm both packs now work side by side. (This is the single most valuable thing to feel rather than just read.)
Tag instead of override. Find a place where your pack replaces a vanilla file, and see whether you can express the same intent by adding to a tag without "replace": true instead, so your change merges with other packs’ instead of overriding them. (Not everything can be done this way; the goal is to notice when it can.)
Ship it for real. Zip your pack correctly, write a README, choose a license, and, if you’d like, actually upload it to one of the community sites. Then download your own pack back from the site, install it into a fresh world, and make sure it works. Shipping something and watching it install cleanly is the best possible final exercise.
Snapshot your project. Initialize Git in your pack folder and make your first commit. Change one function, commit again, and look at the two-entry history you just created.

What Can Go Wrong

The zip has a wrapper folder. You compressed the containing folder instead of the pack’s contents, so the zip opens to a folder instead of pack.mcmeta, and the game won’t list the pack. Re-zip from inside the pack folder so pack.mcmeta sits at the root. (Most common publishing mistake by far.)
No pack.mcmeta at the top, or it’s misplaced. The pack.mcmeta is the only mandatory file, and its presence is what identifies the folder or zip as a pack. If it’s missing, misspelled, or buried in a sub-folder, the game sees no pack at all. Check it’s spelled exactly pack.mcmeta and lives at the top level.
A reused namespace causes a silent clash. Two packs sharing a namespace (or both overriding the same minecraft: file) collide, and only the later one’s files take effect, with no error message, because overriding is normal, expected behavior. If something stops working only when two packs are loaded together, suspect a path/namespace collision and give your content a unique namespace.
A broken description hides the pack. The description is a text component (Chapter 5), so a JSON typo there (a missing comma, an unclosed bracket) can make the whole pack.mcmeta fail to parse, and a pack with an unreadable pack.mcmeta won’t load. If your finished pack vanishes from the list right after you styled the description, re-check that JSON first.

What You Know Now

You can take a working data pack and turn it into something other people can find, trust, and run. You can write a description that actually sells the pack and add a pack.png icon; you can organize your files so a human can read them; you understand why packs collide (same path, later pack wins) and you know that keeping everything under your own namespace is what prevents it, with tags as the merge-friendly exception. You can package a pack as a .zip with pack.mcmeta at its root, and you know the community sites (Modrinth, Planet Minecraft, CurseForge) where data packs are shared. And you’ve met two ideas that outlast this book: licensing, so people know how they may use your work, and Git, so your project’s whole history is always recoverable.

A Word to End On

You started this book as someone who plays Minecraft. You’re ending it as someone who can make Minecraft: someone who looks at an item, a mob, a biome, a dimension, and sees the data files underneath, and knows how to write your own.

Think about how far that is. In the first three chapters you went from “I’ve never made a data pack” to a pack that loaded, announced itself, and added a recipe. From there you learned to talk to the game with commands tucked safely inside functions; to store and track information three different ways and choose the right one; to declare what things are with tags, recipes, loot tables, predicates, and advancements; to build custom items out of components instead of fighting raw NBT; to make functions that take arguments, return answers, and run on a schedule; to dress your creations up with resource packs; and to combine all of it into real projects. The bravest among you went further still, into data-driven enchantments, villager trades, dialogs, and the deep magic of world generation: biomes, structures, dimensions, and the noise and density functions that sculpt terrain itself.

All of that adds up to a way of seeing. Modern Minecraft is data-driven from top to bottom (“vanilla is just a data pack”) and you now think in that system instead of hacking around it. The same instinct that told you to add to a tag instead of overriding a file, or to reach for command storage instead of bending scoreboards, is exactly how the people who build the game think.

There will always be one more registry to explore, one more component, one more corner of worldgen. That’s the good news: you’ll never run out of things to make. When you hit something this book didn’t cover, you already know what to do: find the data file behind it, read what it expects, change one thing, /reload, and see what happens. That loop is the whole craft, and it’s yours now.

So pick an idea that’s been rattling around your head (the weird item, the silly minigame, the world that shouldn’t exist) and go build it. Then share it, so the next person who’s just discovering that Minecraft is made of files has something of yours to learn from.

Thanks for building alongside us. Now go make something only you would make.

— The End —

Keyboard shortcuts

Minecraft Data Packs: A Complete Guide