Guide · Reference
pack_format explained
Every Minecraft resource pack declares which game versions it was made for via a number in pack.mcmeta. Get it wrong and Minecraft warns the pack is incompatible. This guide explains where the number comes from, how it has changed over the years, and includes a full lookup table.
What pack.mcmeta does
At the root of every resource pack sits a small JSON file called pack.mcmeta. It holds the pack's description (shown in the in-game pack list) and a format number that tells Minecraft which versions the pack's file layout targets. A classic one looks like this:
{
"pack": {
"pack_format": 34,
"description": "My custom music pack"
}
}The format number is not decorative. When Mojang reorganises asset paths, renames files or changes how textures and sounds are read, the format number is bumped so the game knows which rules to apply. A music-only pack is rarely affected by those internal changes — the sounds/records path has been stable for years — but the warning still appears whenever the number doesn't match the game.
A short history of the number
Resource packs (and pack_format) arrived in Java Edition 1.6, replacing the older texture pack system. For nearly a decade the number crept up slowly — format 1 covered everything from 1.6 to 1.8.9, and by 1.16 it had only reached 6. From 1.19.3 onwards Mojang began bumping it far more aggressively, sometimes several times within a single minor version, which is why the table below jumps from 9 to 12 to 13 and then races upwards.
Two bigger changes followed. First, from Java Edition 1.21.9 the single number was replaced by a range: min_format and max_format let a pack declare the whole span of formats it supports, so one zip can stay valid across several releases. Second, Minecraft moved to year-based version numbers — the release after 1.21.x is 26.1, named for 2026 — and pack formats continued counting upwards underneath (26.1 ships with format 84).
The dual code path in pack.mcmeta
Because of the 1.21.9 change, a correct generator has to write two different shapes of pack.mcmeta depending on the target version. MineVinyl does exactly this:
- 1.6 – 1.21.8: a single
pack_formatnumber matching your selected version. - 1.21.9 and later (including 26.x): a
min_formatset to your version's format and a highmax_format, so the pack keeps loading cleanly on future releases.
If you ever edit a generated pack by hand, keep this split in mind — pasting a modern range-style mcmeta into a pack for 1.20 (or vice versa) is a common cause of the incompatibility warning.
Lookup table: game version → pack format
This is the same mapping MineVinyl's generator uses when it writes your pack.mcmeta:
| Java Edition version | Pack format |
|---|---|
| 1.6.1-1.8.9 | 1 |
| 1.9-1.10.2 | 2 |
| 1.11-1.12.2 | 3 |
| 1.13-1.14.4 | 4 |
| 1.15-1.16.1 | 5 |
| 1.16.2-1.16.5 | 6 |
| 1.17-1.17.1 | 7 |
| 1.18-1.18.2 | 8 |
| 1.19-1.19.2 | 9 |
| 1.19.3 | 12 |
| 1.19.4 | 13 |
| 1.20-1.20.1 | 15 |
| 1.20.2 | 18 |
| 1.20.3-1.20.4 | 22 |
| 1.20.5-1.20.6 | 32 |
| 1.21-1.21.1 | 34 |
| 1.21.2-1.21.3 | 42 |
| 1.21.4 | 46 |
| 1.21.5 | 55 |
| 1.21.6 | 63 |
| 1.21.7-1.21.8 | 64 |
| 1.21.9-1.21.10 | 69 |
| 1.21.11 | 75 |
| 26.1+ (latest) | 84 |
What happens if the number is wrong?
Minecraft shows a “made for an older/newer version” warning and asks whether to load the pack anyway. For a music-disc pack it is almost always safe to click through, because sound file paths haven't changed — but the warning is ugly and worries players you share the pack with. The clean fix is to regenerate the pack with the right version selected, which takes seconds in the generator. If the pack misbehaves in other ways, see the troubleshooting guide.