Mod Menu makes a Fabric modpack browsable, with an API for mod authors

A mod list that doubles as a settings launcher

The README states the purpose in a sentence: Mod Menu lets you view the mods you have installed and, if supported by the mod, enables quick and easy access to the mod's config screens. The screenshot description at the top of the file shows the layout, with a list of mods on the left under a search bar and a filters button, and on the right the details for the selected mod, including authors, a description, links, credits, and a button to configure the mod. That last element is the whole point. A Minecraft pack with a hundred mods has a hundred config screens scattered across keybind menus and mod specific interfaces, and Mod Menu turns that into one list with a settings button per entry. The condition in the README is important, that access to the config screen works if the mod supports it, so this is an opt in from the mod author's side rather than a guarantee. The supported platform statement is narrow and worth quoting: Mod Menu is currently available for Fabric or Quilt on Minecraft Java Edition 1.14 or newer. The audience is therefore the Java Edition player on a modern loader, not the whole Minecraft ecosystem, and the project is a client side mod, which is why it can see the mod list at all.

The features that go beyond a list: filtering, translations and updates

The advanced features paragraph is denser than the description, and it reveals what the project is actually for. It supports translatable mod names and descriptions, and it supports QuickText formatting in mod descriptions thanks to Patbox's Text Placeholder API. It filters library mods out from regular mods, which is the feature that separates this from a simple mod list, because a modern pack is mostly libraries and a list that shows them all is noise. It provides a mod update checker for mods hosted on Modrinth or that provide their own update sources, and it provides deep configuration for all the features it offers. The update checker is the most interesting of these, and the metadata API section explains how it works by default: it uses the hash of your mod's jar to look up the latest version on Modrinth, and if it finds a matching project it checks for the latest version that supports your mod loader and Minecraft version, and if that version has a different hash from the existing file it prompts the user that an update is available. The hash comparison is the detail that makes it safe. It is not comparing version strings, it is comparing the artifact, so a repackaged or modified jar will not be treated as an outdated copy of itself.

The translation API: no Java required to localise a mod

The developer facing side starts with the translation API, and its selling point is stated plainly: you can translate your mod's name, summary, and description all without touching any Java code. The mechanism is a set of translation keys in a supported format, added to any language you like. The documented example is Mod Menu's own translations into Pirate Speak, and the naming rule is the part to get right, since you replace modmenu at the end, and not the one in the beginning, of the translation key with your own mod ID. So the key form is modmenu.descriptionTranslation.traverse for a mod with the ID traverse.

{
    "modmenu.nameTranslation.modmenu": "Menu o' mods!",
    "modmenu.descriptionTranslation.modmenu": "Menu o' mods ye installed matey!",
    "modmenu.summaryTranslation.modmenu": "Menu o' mods ye installed matey!"
}

There are three separate keys, one for the name, one for the description and one for the summary, where the summary is a short one sentence description of the mod. The README notes that the summary translation in the example is redundant because it repeats the description, and that it was included to show that you may translate the summary separately from the description even in English, which matters for languages where a one line summary does not simply shorten the longer text. For a mod author this is the cheapest possible localisation story, since the strings sit next to the other language files and no code changes when you add a language.

The metadata API: badges, links and parents in fabric.mod.json

The Fabric Metadata API covers everything that can be declared in the mod's own fabric.mod.json under a custom block for Mod Menu. The example shows the shape, with a links object, a badges array, a parent object and an update_checker flag.

{
  ...
  "custom": {
    "modmenu": {
      "links": {
        "modmenu.discord": "https://discord.gg/jEGF5fb"
      },
      "badges": [ "library", "deprecated" ],
      "parent": {
        "id": "example-api",
        "name": "Example API",
        "description": "Modular example library",
        "icon": "assets/example-api-module-v1/parent_icon.png",
        "badges": [ "library" ]
      },
      "update_checker": true
    }
  }
}

Badges are the interesting restriction. The Client badge is added automatically to mods set as client side only, and other badges such as the Library and Deprecated badges require definition in the metadata. The supported values are library, for mods that are purely dependencies for other mods and should not be shown to the user by default unless they toggle them on, and deprecated, for mods that exist purely for legacy reasons such as an old API module. Any other value is ignored, and Mod Menu does not support adding your own badges, though an issue can be opened if there is a compelling use case for a new one. Links work by translation key, so a key of modmenu.discord shows as the text Discord because that is the English translation Mod Menu provides, and all default link translation keys take the form modmenu.<type>. Custom keys are allowed, and the README asks that you use your own namespace rather than modmenu for them. The parent mechanism is for mods split into modules, where a mod is displayed as a child of another, and it also supports a dummy parent that is not a real mod, which is useful as a grouping bucket and as a fallback for an optional parent, and dummy parents only support id, name, description, icon and badges.

Opting out of the update checker, and the Java API

The last documented metadata switch is update_checker, and it matters because the default behaviour is to look things up on Modrinth. Setting it to false in the Mod Menu metadata disables that.

"custom": {
    "modmenu": {
        "update_checker": false
    }
}

The reason to disable it is not hard to guess from the mechanism, since the lookup uses the hash of the mod's jar, so a mod that is not on Modrinth or whose build is not published there gets a lookup that finds nothing, and a mod distributed elsewhere may prefer to handle its own updates. The README also lists the general developer surface, saying that Mod Menu includes a number of APIs for developers to improve how their mod appears in Mod Menu, and that these come in the form of language keys, JSON metadata and even a Java API. The three tiers are worth separating, because they have very different costs. Language keys cost nothing but a file. JSON metadata costs nothing but a block in a file you already have. The Java API is the one that costs code, and it is the only route to features that metadata cannot express, which in practice means custom mod pages rather than configuration. The README does not document the Java API in the excerpt available here, so a mod author who needs more than badges and links will have to read the source.

Building it, and the version lines to expect

The repository is a Gradle Java project with a build.gradle, settings.gradle, gradle.properties, a gradle wrapper with the Windows batch variant, and a src/ directory, so building from source is a standard Gradle invocation. The interesting versioning detail is the branch model, and the default branch here is named 26.4, which is a Minecraft version rather than a Mod Menu version. The release list explains why: v22.0.0-alpha.2 is the release for 26.4-snapshot-3, v22.0.0-alpha.1 is for 26.4-snapshot-1, and v20.0.3 is for 26.2. So the Mod Menu version and the Minecraft version move separately, with alphas tracking the new snapshots and a stable line tracking the current release, which is the pattern you would expect from a mod that has to work against a fast moving platform. The last push was on 2026-10-17 and the repository is not archived, so the project is being worked on. The licence is MIT, with a LICENSE file at the root, which is the permissive end and means the mod can be redistributed or embedded in a pack with minimal obligations, though a pack that bundles many mods is a separate licensing question. The limits of the project are structural rather than technical. It is a client side mod on a specific loader, it can only offer a config screen for mods that implement one, and it can only manage updates for mods it can find a matching published artifact for, so a pack of mods from mixed or private sources will always have a manual part.

Editorial conclusion

Mod Menu suits a Minecraft Java player on Fabric or Quilt who has a modpack large enough that finding a setting is a chore, and a mod author who wants their mod to appear properly translated and properly grouped rather than as a bare name in a list. It is the wrong tool for a player on a different loader or an older Minecraft version, since the README states it is available for Fabric or Quilt on Minecraft Java Edition 1.14 or newer, and it is the wrong tool if you want to change mod settings rather than reach them, since the point is to open the mod's own config screen. Before you add it to a pack, check that your version of Minecraft and your loader are in range, and if you are a mod author, read the metadata API section, because the badges and the update checker are opt in through fabric.mod.json and the default behaviour is not always what you want.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. TerraformersMC/ModMenu on GitHub