One of the first questions players have when they first get into Minecraft modding is “Why are there so many mod loaders?” followed by a series of Google searches to check which mod loader their favourite mod works with.
Despite Minecraft’s reputation for design simplicity, the modding process requires selecting from several competing and often incompatible mod loaders; the primary of which are: Forge, Fabric, NeoForge and Quilt. The multiplicity of these mod loaders is the direct result of over a decade of continuous technical evolution, innovation, and most importantly, disagreements.
1. The Pre-API Era
Minecraft Modding began very early in the game’s early development, predating the existence of formal tools or loaders. This initial period, approximately from 2009 through the Alpha and early Beta stages. The way this was done was by directly modifying the game’s core files, a process known as “jarmodding”. While this was technically quite rudimentary, it established the cultural foundations of modding.
The Manual Modding Process:
Minecraft Java Edition is distributed as a .jar file. This is a specialized .zip archive which also contains some compiled Java code (.class files) and the game assets. Early modders discovered that this archive could be edited directly, which involved opening minecraft.jar and replacing the vanilla .class files with edited ones.
To prevent tampering, Mojang digitally signed the .jar file contents, storing these signatures in a folder called META-INF. Since any changes to the games files would invalidate the signatures and stop the game from launching, players who wanted to mod their games would have to delete this folder to bypass the security check.
Mod Coder Pack:
One of the big obstacles for developers was code obfuscation. Obfuscation is the practice of making code intentionally difficult to read or edit in order to restrict tampering or to deter reverse engineering. Unfortunately for mod developers, that’s exactly what they needed to do. Before releasing the game to the public, Mojang used a tool called ProGuard to optimize and obfuscate their code. The software reduced the filesize but rendered the decompiled source code almost unreadable for modders. Almost.
In 2010, a team, including Michael “Searge” Stoyke developed the Mod Coder Pack (MCP). It was a set of scripts that automated the setup of a modding environment. The main function of this was deobfuscation. MCP utilized a large community-sourced database of mappings to translate the obfuscated code back into human readable code. And thereby allowing modders to decompile the game, edit what they needed to and re-obfuscate the modded code. MCP was incredibly important, it made Minecraft’s code legible which contributed directly to the growth of modding communities.
Incompatibility and Divergence:
This method of direct file replacement had one persistent issue, compatibility. Because early mods worked by overwriting the base game files, two mods that altered the same file wouldn’t work together. The only way two mods were compatible was if someone manually merged the code and recompiled it, or if neither of the mods changed the same files.
What complicated development even more was that there were separate codebases for Single-Player and Multi-Player. A mod made for one mode was not compatible with the other, often requiring mod developers to create two different versions of their mod. These technical challenges of the era created a strong demand for a more structured system. Mojang’s stance on the matter was implied; they did not take any legal action against modding efforts, allowing the community to come to its own solutions. It was during this era that we saw the first instances of Mojang hiring mod developers, such as Searge from the MCP team.
2. Early APIs
The first widely adopted solution to the ‘jarmodding’ problem was Risugami’s ModLoader. The project, while simple by modern standards, was a significant conceptual advancement by introducing the idea of a standardized modding Application Programming Interface (API) to the Minecraft Community. An API is a type of software interface that allows computers or their programs to interact with each other.
Risugami’s ModLoader:
The ModLoader addressed the incompatibility problem by acting as a single, foundational mod that made a series of common edits to the game’s base files. Other mods could then be designed to “hook” into the ModLoaders code instead of modifying the main game’s base code. This enabled them to perform functions such as adding new blocks, items or recipes without creating file conflicts; a major innovation allowing the use of multiple simple mods simultaneously. Thus establishing Risugami’s ModLoader as the de facto loader for a considerable time.
Minecraft Bedrock Edition:
In 2011, Mojang began development on Minecraft: Pocket Edition. This C++ based version of the game would later be expanded and ported to other platforms, ultimately being renamed Minecraft: Bedrock Edition in 2017 with the “Better Together Update,” which unified the non-Java versions and enabled cross-platform play. Its separate codebase meant its development proceeded in parallel to, but largely separate from, the Java Edition modding scene.
Server-Side APIs:
Alongside this, server-side mods evolved as well, with platforms like Bukkit and its successor, Spigot. These platforms introduced “plugins”, which changed server behaviour (eg. Economy, Land Protection) without requiring client-side mods. A player with an unmodded game client could connect to a bukkit or spigot server and experience custom features. This established a distinction between mods, which generally added client-side features, and plugins, which were exclusively server-side. The Bukkit project gained significant traction, and several of its lead developers were hired by Mojang in 2012 to develop an official modding API. A project that was never delivered for Java Edition.
There was further evolution in this space with the introduction of the Paper Project (Originally PaperSpigot), which was a performance-oriented fork of Spigot launched in 2014. It maintained plugin compatibility while providing significant performance gains. This has led to wide adoption and becoming the most widely used server software in the Bukkit Ecosystem.
To connect multiple servers in one network, proxy software was developed. BungeeCord was an early solution for this, however more recently Velocity has emerged as a modern high-performance alternative. Developed by the PaperMC Velocity was designed for better scalability, security, and support for modern modded environments, including support for Paper, Fabric, and Forge servers.
Limitation and Centralization Risks:
While revolutionary for the time, Risugami’s ModLoader had many limitations. The API was designed mainly for Risugami’s own mods and so only supported basic functionalities. With more and more ambitious mods coming out such as IndustrialCraft, BuildCraft and Redpower, they required extensive changes to the game code, something that the existing ModLoader could not do. As a result, the compatibility issues persisted.
The long-term sustainability of the project was becoming increasingly uncertain, primarily due to the reliance on a single developer. As Minecraft got new updates, Risugami’s own updates became less frequent and sometimes contained unresolved bugs. The fragility of the ecosystem was especially highlighted during the formation of the “Feed The Beast” (FTB) modpack. Risugami has an unwritten policy of denying explicit requests for permission to distribute ModLoader. Which was a problem since nearly every mod in FTB at the time depended on ModLoader. The community started to seek a more dedicated and collaborative platform. As alternative solutions surfaced, Risugami’s ModLoader development ceased, with a final update for Minecraft 1.6.
3. Forge & NeoForge
As the constraints of ModLoader became clear, developers of the most complex and popular mods needed a more capable solution to the incompatibility problem. This led to a collaborative project that would become the standard for modded Minecraft for nearly a decade: Minecraft Forge.
The Collaborative Library:
Initially, Minecraft Forge was not a Mod Loader. It was an API library designed to operate on top of existing ModLoader Framework. A group of mod authors including Eloraam (Redpower) and SpaceToad (BuildCraft) created the Project. In order to resolve the incompatibility between their mods, they consolidated their required base-class edits into a single shared d library. This collaborative approach was quickly adopted by other major mods.
Forge:
The transition from a library to a complete modding platform was a response to the declining reliability of the ModLoader Project. The Forge team developed its own replacement: The Forge Mod Loader (FML). By integrating the previous libraries into FML, Forge became a comprehensive, all-in-one solution to Minecraft Modding. The success of Forge was largely due to its commitment to providing a stable API. The way it works is through a standardized event system, allowing mods to react to in-game occurrences without directly altering the underlying game code. The event-driven architecture, along with an extensive library of hooks, significantly improved compatibility. Large interconnected modpacks such as Tekkit and Feed The Beast were now possible. For about 7 years, Forge was the dominant mod loader for the vast majority of the modding community.
As is common with community -led projects, eventually the original leadership of Forge transitioned. The founding developers passed control of the project to one LexManos, who would oversee continued development from then forth. The leadership style and technical philosophies established during this period would later become the source of conflict within the community.
NeoForge:
In 2023, the next significant fragmentation was due to community disagreements rather than necessity. Discontent has been growing in the Forge development team regarding the project’s leadership and management style, which some mod developers found to be an increasing hindrance to collaboration and technical progress.
In July 2023, a majority of the Forge development team, including cpw, the original creator of the Forge Mod Loader, publicly announced their departure from the project. As the “Forge” brand and key assets were controlled by a company associated with the project lead, the team forked the codebase under a new name. NeoForge.
The stated objective of this new project was to be the successor to Forge while being more transparent and having a ‘community-driven governance structure’. From a development standpoint, the project aimed to address the accumulated technical debt, refactor complex systems and improve the developer experience by adopting modern practices. For Minecraft version 1.20.2 and newer, NeoForge is effectively the continuation of the Forge lineage, with a significant portion of mod developers migrating to the new platform.
4. Fabric & Quilt
For almost 10 years, the Minecraft modding community was largely unified under the Forge platform, This period of stability concluded with the release of Minecraft 1.13: The Aquatic Update in July 2018. The update introduced fundamental changes in how the game’s code worked and effectively rendered the existing mods and tools obsolete.
Minecraft 1.13:
In this update, Mojang did what they called “The Flattening”. Prior to this, blocks and items were identified by a numeric ID and a “metadata” value, a system which quickly was approaching its limit. The Flattening replaced this system by instead, assigning every block and item variant a unique, namespaced string ID (eg. minecraft:stone, or minecraft:bread). This change, along with other significant rewrites such as an overhaul of the command parser and introduction of “data packs”, invalidated the foundational logic of all existing mods.
Fabric:
The scale of these changes necessitated a complete rewrite of the Forge Mod Loader, an undertaking which took many months to complete. In the meanwhile, the modding community was in a state of suspension since players were unable to use their favourite mods with the new content and developers could not update their mods. This extended delay was what disrupted the momentum of the pre-1.13 modding era. The delay in Forge’s update created a vacuum which allowed for an alternative mod loader to enter the scene.
Rift was an early attempt; a proof of concept for Minecraft 1.13.
The more permanent successor was Fabric. Developed for Minecraft 1.14, Fabric was designed from ground up to be a lightweight, modular and most important, quick and easier to update to new version, mod loader. In contrast to Forge’s monolithic structure, Fabric was a minimal toolchain. (A toolchain is a set of programming tools that allow the user to create a software or a product.) The core design principle was to make as few changes to the vanilla game as possible, which allowed it to be updated for newer Minecraft versions, including snapshots, in a matter of hours or days rather than months. The quick updates were in direct response to the community’s frustration with Forge’s slow adaptation to Minecraft 1.13.
Quilt:
Similar to Forge, a division, stemming from disagreements, occurred within the Fabric community. A group of community members and developers expressed dissatisfaction with the Fabric project’s management, citing concerns about moderation policies and a perceived lack of transparency and centralization in the governance structure.
In response, this group forked the Fabric toolchain in 2021-2022 and created Quilt, with the mission being to build on Fabric’s technical foundation while establishing a more decentralized and transparent community structure. Quilt maintained compatibility with most Fabric mods and aimed to enhance the developer experience with improved tooling such as the Quilt Standard Libraries (QSL) and the QuiltFlower decompiler, a more open approach to code mappings.
5. The Current Landscape
Following the fragmentation after Minecraft 1.13, the modding community stabilized around two dominant platforms with pretty distinct characteristics.
Forge Vs. Fabric: The Duopoly:
- Forge continued to be the platform for large scale modpacks that significantly alter the core gameplay experience. Its primary strength remains in its extensive API, which provides a standardized system for functions like energy and item transport. This built in compatibility layer enables large mods such as Create, Tinker’s Construct, and Thermal Series to function together with high stability.
However, Forge’s comprehensive nature leads to higher resource consumption, making it heavier on the computer, longer load times and of course, slower updates to newer Minecraft versions. - Fabric has established itself when it comes to performance optimization and “vanilla-plus” mods. The lightweight design allows for faster game loading and smaller performance footprint. This efficiency, along with the use of mixins, has facilitated the development of the most popular performance mods such as Sodium, Lithium and Iris.
Fabric’s main advantage is in its rapid update cycle; the toolchain is often compatible with new Minecraft versions, including snapshots, in a very short period of time. The trade-off being that its less structured API can result in more compatibility issues between large content mods.
The Difference in Approach:
- Forge’s Approach: A heavyweight, API-centric platform. It provides a large, pre-built library of hooks and a structured event system. The objective is to create a managed environment where mods interact primarily through the Forge API instead of directly with the game’s code. This allows for compatibility between complex mods by enforcing standardized systems and maintains stability through structured control.
- Fabric’s Approach: A lightweight, minimalist toolchain. The core loader is small, relying instead on a technology called mixins. A mixin allows a developer to inject code directly into any part of the game’s code at runtime, effectively patching the game on the fly. This provides developers with significant power and flexibility to modify any aspect of the game. Essential APIs are available through a separate optional library called the Fabric API.
6. Interoperability and The Future
This fragmentation in Minecraft modding presents a rather large issue for both developers and users. If you are a developer, which platform do you develop for? If you are doing both, do you have the time or resources to maintain that? For users, what happens if your favourite mods are on two different platforms?
Interoperability Solutions:
The incompatibility between Forge/NeoForge and Fabric led to the development of the Sinytra Connector. A compatibility layer that allows Fabric mods to run on NeoForge (and legacy Forge). The Connector functions as a translation layer by implementing a version of Fabric on top of Forge, called “Forgified Fabric API” and translating the calls between the two systems. This allows users to run Fabric mods on NeoForge, often without too much issue. While not all mods are compatible, it does represent a significant step forward in bringing these platforms just a little bit closer together.
An Official Modding API:
For the longest time, the Minecraft community has asked for an official Mojang-supported modding API for Java Edition, with supporters arguing that an official API would resolve the “loader wars” and ensure stability across Minecraft updates. Mojang hired the Bukkit team in 2012 with the stated purpose of creating such an API. However, this project was eventually abandoned for Java and Mojang’s development focus shifted to Bedrock Edition, which received a more limited, sandboxed “Add-On” system. For Java Edition, Mojang expanded the capabilities of Data Packs allowing for custom features such as recipes, loot tables and world generation, but they do not provide the same level of power as the existing mod loaders. Mojang has since stated that they have no plans on creating a full Java modding API, implying that the community has developed effective solutions that don’t require their involvement. While this decision is frustrating for some, Mojang’s non-interventionist approach has arguably fostered a uniquely versatile modding environment unlike any other game. The freedom to modify the game’s code directly is what enables mods like we see today, something that an official API would most likely put a damper on.
Trajectory of Modding Community:
Currently, the split between Forge and NeoForge appears to be resolving, with NeoForge setting itself up as the de facto successor to Forge-style modding on Minecraft 1.20.2 and newer. Most major mod developers have stated their intention to migrate to the new platform leaving Legacy Forge to support older game versions.
More importantly, Mojang has announced and put into effect their accelerated update schedule. In 2024, the idea of smaller, more frequent “game drops” were introduced. This faster pace may increase maintenance burdens on developers who now have to constantly update their mods. This could lead to several potential outcomes.
First, players and developers could informally adopt a specific stable version for long-term development, as with what happened with 1.7.10, 1.12.2, 1.16.5 and 1.20.1 to create platforms for large modpacks.
Alternatively, it could encourage developers to write more version-agnostic code. The future of Minecraft modding is likely to evolve with attempts to balance the latest game version and maintaining a stable development environment.
Summary Comparison of Mod Loaders
| Mod Loader | Core Idea | Approach | Origin | Strength |
| Forge | Stability through a comprehensive, centralized API. | Heavyweight Event Bus, extensive hooks for inter-mod compatibility. | The legacy standard for large, content-heavy modpacks. | Massive library of established content mods for older versions (pre-1.20). |
| Fabric | Speed and flexibility through a minimalist, modular toolchain. | Lightweight loader with a powerful Mixin-based injection system. | A reaction to Forge’s slow update to Minecraft 1.13, prioritizing update speed. | Best-in-class performance and optimization mods; fastest updates to new versions. |
| NeoForge | Modernizing Forge’s API with community-driven governance. | A direct fork of Forge, focused on refactoring legacy systems and improving developer experience. | A reaction to Forge’s project leadership and accumulated technical debt. | The de facto successor to Forge for versions 1.20.2+, attracting most major mod developers. |
| Quilt | Improving on Fabric with better tooling and transparent governance. | A fork of Fabric with an expanded API (QSL) and improved tooling (e.g., decompiler). | A reaction to Fabric’s community governance and moderation policies. | Full compatibility with Fabric mods, plus access to Quilt-exclusive mods and improved developer tools. |
Conclusion
The fact that there are so many different Minecraft mod loaders is not necessarily a bad thing. On the contrary, it is a testament to how adaptive communities can be to overcome technical challenges in order to achieve their goal. Each new platform was created as a direct response to a technical or social issue of its predecessor and Minecraft’s development trajectory.
- Risugami’s ModLoader was the first answer to the problem of Mod incompatibility by introducing a rudimentary API.
- Minecraft Forge looked to address the need for a more robust system capable of supporting complex interoperable mods, enabling an era of large scale modding.
- Fabric was created in response to a need for a mod loader that could adapt more quickly to major game updates.
- NeoForge and Quilt show the need for a more transparent and accountable governance structure in open-source software development, proving that to remain sustainable, it is important to have a good social structure.
The current modding environment is a competitive one, and competition is what drives innovation. The history of Minecraft mod loaders is one of twists and turns, all of which culminate just so we can play our favourite games the way we like them.
