If you are making a Minecraft Bedrock add-on, the UUID generator you need is any tool that makes standard random UUIDs, because each pack's manifest.json needs its own unique IDs. Microsoft's pack manifest docs recommend an online service for this, and AyeTab's free UUID generator gives you as many as you need in one click.
Why Minecraft packs need UUIDs
Every behavior pack and resource pack for Bedrock Edition has a manifest.json file. According to Microsoft's reference, the uuid in the header is a special identifier that tells this pack apart from every other pack. The game uses it to recognize your pack, so two packs should never share one.
The format is the standard one: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, where each x is a hex digit from 0 to 9 or a to f. That is exactly what a regular UUID generator produces.
Where each UUID goes
A manifest uses UUIDs in up to three places:
| Field | What it identifies | Rule from Microsoft's docs |
|---|---|---|
header.uuid |
The pack itself | Unique to this pack |
modules[].uuid |
Each module inside the pack | Different from the header UUID and from every other module |
dependencies[].uuid |
Another pack this one relies on | Must match that other pack's header UUID exactly |
So a simple behavior pack with one data module needs two fresh UUIDs: one for the header and one for the module. If it also depends on your resource pack, the dependency entry reuses the resource pack's header UUID rather than a new one.
Step by step
- Open a generator. Go to the AyeTab UUID generator on the web app, or open a new tab if you have the AyeTab Chrome extension installed and press Ctrl+K or Cmd+K, then type "uuid".
- Choose how many. Count the header plus each module across all your packs. A behavior pack and a resource pack with one module each need four.
- Press Generate and copy. AyeTab makes random version 4 UUIDs with your browser's built-in
crypto.randomUUID(). Nothing is sent to a server and you do not need an account. - Paste them into your manifests. Put one in each header and each module.
- Link the packs. In the behavior pack's
dependencies, paste the resource pack's header UUID, not a new one.
Microsoft's example behavior pack shows the pattern: a header UUID, a separate UUID for each module, and a dependency entry that points to another pack by its UUID.
Common mistakes
- Copying a manifest from a tutorial and keeping its UUIDs. Your pack would then share IDs with everyone else who did the same. Always generate fresh ones for a new pack.
- Reusing the header UUID for a module. The docs say modules need their own.
- Generating a new UUID for a dependency. A dependency must match the other pack's header UUID, or the link will not work.
- Typing UUIDs by hand. It is easy to produce something that only looks right. Generate them.
When to change a UUID
Keep the same header UUID when you update a pack and raise its version instead. Microsoft's docs say that when a pack is imported again, the new one replaces the old one only if its version is higher. Make a new UUID only when you are building a separate pack that should sit next to the original.
Other ways to generate them
If you build packs with scripts, Python's uuid.uuid4() or the browser's crypto.randomUUID() produce the same kind of value, and on Windows PowerShell has New-Guid. For hand-built packs, a browser tool is simpler, and AyeTab is free, quick to open and works offline once the extension is installed. Any standard v4 generator works, so use what you have open.
Frequently asked questions
Can I use any UUID generator for Minecraft packs? Yes, as long as it outputs standard UUIDs in the 8-4-4-4-12 hex format. A random v4 UUID from AyeTab fits.
Do the module UUIDs need to be different from the header? Yes. Microsoft's manifest reference says each module UUID should differ from the pack's header UUID and from every other module.
Does a dependency need a new UUID? No. It must be the exact header UUID of the pack it depends on.