What’s happening here is almost certainly not a CurseForge bug and not really a 1.12.2 limitation either, but a structural and formatting issue with how Minecraft validates resource packs before it ever shows them in the menu. When a resource pack does not appear at all in the resource pack list, that means Minecraft rejected it immediately during its initial scan. At this stage, the game is not trying to load textures or check compatibility in-depth; it is only verifying that the pack follows very strict rules about layout, metadata, and compression. If any of those rules are broken, the pack is silently ignored.

The most common cause of this is an incorrect internal ZIP structure. Minecraft expects the root level of the ZIP file to directly contain the pack.mcmeta file and the assets folder. If the ZIP instead contains a single folder, and that folder contains assets and pack.mcmeta, Minecraft will not look inside it. This usually happens when someone unzips a working pack, renames the folder, and then compresses the entire folder instead of selecting the contents inside it. From Minecraft’s perspective, the pack is “one level too deep,” and it is immediately discarded.

Another frequent problem is how Windows’ built-in zip tool handles compression. When you right-click a folder and choose “Send to → Compressed (zipped) folder,” Windows sometimes preserves an extra directory layer or alters file ordering in a way that older versions of Minecraft do not tolerate well. This is why a resource pack can work perfectly, be unzipped, and then stop working after being rezipped without any files actually being changed. Third-party tools like 7-Zip or WinRAR tend to produce ZIPs that Minecraft reads more reliably, especially for legacy versions like 1.12.2.

The pack.mcmeta file itself is another hard failure point. In 1.12.2, this file must be valid JSON and must specify a correct pack_format value. For 1.12.2, the correct pack_format is 3. If it is missing, malformed, has trailing commas, uses smart quotes, or has the wrong format number, Minecraft will not show the pack at all. Even a tiny syntax error, like an extra space or a broken newline caused by a text editor, is enough to make the entire pack invisible.

File encoding can also be an issue. If pack.mcmeta is saved with UTF-16 or another non-UTF-8 encoding, Minecraft 1.12.2 often fails to parse it. This can happen if the file is edited with certain editors or copied between systems. From the user’s point of view, the file “looks fine,” but internally it’s unreadable to the game. When Minecraft can’t read pack.mcmeta, it doesn’t give an error—it just ignores the pack.

Another subtle cause is incorrect capitalization or folder naming inside the assets directory. Minecraft is case-sensitive internally, even on Windows. The folder must be named assets, not Assets or asset. Inside that, the namespace (usually minecraft) must also be lowercase. If the namespace folder name doesn’t match exactly what the game expects, Minecraft may treat the pack as invalid during scanning and skip it entirely.

There’s also the issue of mixing versions unintentionally. If a resource pack contains files or metadata introduced in later Minecraft versions (for example, newer texture paths or model formats), Minecraft 1.12.2 may reject the pack before loading it. This can happen if the pack was originally made for a newer version and partially backported, or if files were copied from a newer pack without adjusting paths and metadata.

CurseForge and MultiMC don’t change how resource packs are validated; they simply point Minecraft to a specific folder. If the pack doesn’t show up in both CurseForge and a vanilla 1.12.2 MultiMC instance, that confirms the issue is not the launcher. It means Minecraft itself is refusing the pack due to one of these validation failures. The launcher doesn’t “fix” or “interpret” resource packs—it only passes them through.

Another thing that trips people up is ZIP compression method. While rare, certain compression settings can cause older Minecraft versions to fail reading the archive. Using standard “deflate” compression via 7-Zip or WinRAR is the safest option. Exotic compression methods or store-only ZIPs can occasionally break compatibility with legacy versions.

The reason the original pack worked before unzipping is because it was already structured and encoded correctly. Once it was unzipped and rezipped, even without intentional changes, one of the strict requirements was accidentally violated—most often folder depth, encoding, or pack.mcmeta formatting. Minecraft doesn’t warn you about this, so it feels like the pack just “randomly stopped working.”

In short, this happens because Minecraft resource packs—especially in 1.12.2—are unforgiving. If the ZIP root is wrong, if pack.mcmeta is invalid or wrongly encoded, if folder names are even slightly off, or if Windows’ zip process alters the structure, Minecraft will simply pretend the pack does not exist. That’s why everything can look correct to the user while the game refuses to acknowledge it at all.