pack.mcmeta: pack_format numbers and the "incompatible" warning
One wrong field makes Minecraft grey out your pack. Here is the shape 26.x requires, how to span old and new versions in one file, and where the file must sit.
Nearly every "my pack shows as incompatible" is one field in one small file.
The file
{
"pack": {
"min_format": 97,
"max_format": 97,
"description": "My pack"
}
}That is a 26.3 resource pack; a 26.3 data pack uses 121. Since 1.21.9, any format past 64 (resource) or 81 (data) must be declared with min_format and max_format. A pack that still writes a bare "pack_format": 97 — what most tutorials, and most generators, still show — is refused and shows as incompatible.
It must be named exactly pack.mcmeta and sit at the root of the zip — next to assets/ or data/, not inside a folder inside the zip. Zipping the containing folder instead of its contents is the second most common failure, and it looks identical to a wrong format number.
Resource packs and data packs use different numbers
This is the part that catches people: the two counters diverged years ago and are not interchangeable. A data pack using a resource-pack number is greyed out even though the number is "current".
Rather than memorising a table that goes stale every release, read the number off a vanilla pack for the version you are targeting — or let a generator fill it in.
One file for old and new versions
Pinning one number means the pack breaks on the next release. A range does not — but a range that reaches into 26.x has to be written for two generations of the game at once:
{
"pack": {
"pack_format": 46,
"supported_formats": { "min_inclusive": 46, "max_inclusive": 64 },
"min_format": 46,
"max_format": 97,
"description": "My pack"
}
}min_format/max_format is the range 26.x reads. pack_format and supported_formats are there only for clients older than 1.21.9: supported_formats must end at exactly 64 (81 for a data pack), min_format must equal its low end, and pack_format must sit inside it. The old advice — supported_formats up to some large number like 99 — is now the one shape 26.x refuses outright. For a pack that only adds textures or recipes — which is most packs — a wide range is honest, because nothing in it actually breaks between versions.
Description takes text components
"description": [
{ "text": "My pack ", "color": "gold" },
{ "text": "v2", "color": "gray", "italic": true }
]Section-sign codes (§6) also still work, but the JSON form survives copy-paste through tools that strip control characters.
Overlays, for supporting several versions at once
"overlays": { "entries": [
{ "formats": { "min_inclusive": 42, "max_inclusive": 45 }, "directory": "older" }
] }The older/ folder at the pack root is used only on those formats. This is how a single download supports two versions with different model formats, instead of shipping two zips.
Quick diagnosis
| Symptom | Cause |
|---|---|
| Greyed out, "made for an older/newer version" | wrong format number, or (1.21.9 and later) no min_format/max_format |
| Pack not listed at all | pack.mcmeta not at zip root, or invalid JSON |
| Loads, textures missing | pack format fine; the texture paths are wrong |
| Works in singleplayer, not on a server | data pack in the wrong world folder |
A trailing comma is invalid JSON and produces the "not listed at all" case, not an error message.
Generate a valid file for your pack type and target version — with min_format/max_format, and the legacy fields where an older version needs them — using the pack.mcmeta Generator.