Reference guide
Minecraft Resource Pack Structure
When a pack starts growing, confusion usually arrives before polish. Textures go into the wrong folder, model files inherit the wrong parent, armor layers get named inconsistently, and newer 1.21.4 item definitions end up mixed with older habits. This page is meant to be the fast reference you open when you want the right path, the right filename pattern, and a clear sense of what belongs where.
The core folders people touch most often
Most pack work circles around a small number of folders. If you are replacing a block face, adding a custom item texture, wiring a blockstate, or exporting armor layers, these are the places that matter first. Once the naming is stable, the rest of the workflow becomes much calmer.
| Type | Pack path | Example name |
|---|---|---|
| Item texture | assets/minecraft/textures/item | diamond_sword.png |
| Block texture | assets/minecraft/textures/block | oak_planks.png |
| Item model | assets/minecraft/models/item | custom_diamond_sword_1.json |
| Blockstate | assets/minecraft/blockstates | crafting_table.json |
| Armor layer | assets/minecraft/textures/models/armor | diamond_layer_1.png |
| 1.21.4+ item definition | assets/minecraft/items | diamond_sword.json |
What changed after 1.21.4
Older tutorials often assume that every custom item decision is made inside models/item through overrides. That is no longer the whole picture. In newer versions, item definitions moved into assets/minecraft/items. The visual logic now lives closer to the item itself, and model selection becomes its own layer instead of staying buried in one long override chain.
That does not make the old folders useless. Textures still live under textures. JSON models still exist when you need them. But if you are migrating or starting fresh for 1.21.4+, it helps to think in terms of three layers: the texture file, the model file, and the item definition that tells Minecraft which visual branch to pick.
A practical assembly order
A clean pack usually comes together in the same order every time. First you export or paint the texture. Then you place it in the right folder. After that you wire the matching model or item definition. Finally you test the item, block, armor piece, or trade in game. When people skip that order, the pack turns into a maze of half-matching names.
- Make or export the PNG.
- Place it in the correct texture folder.
- Create or update the model JSON.
- If you are on 1.21.4+, wire the matching file in
assets/minecraft/items. - Test the result in the generator or in game before adding the next asset.
Typical naming mistakes
The most common failures are boring, but they waste hours. A block texture gets named like an item. A model points to item/foo while the PNG actually sits in textures/block. A file uses uppercase letters or spaces. Or the path is technically valid, but not the path you referenced in the JSON. The safe habit is to keep names lowercase, use underscores, and mirror the same stem across related files whenever possible.
Where to go next
If you only needed the folder map, you are done. If you are actively building, the next useful pages are usually the generator guide, the CustomModelData explainer, and the newer migration notes for 1.21.4. Those pages pick up where this reference stops and move from folder logic into actual commands, item behavior, and model routing.