Fix Fabric's "Incompatible Mods Found!" Crash

The fix is printed inside the error, in a section headed A potential solution has been determined: that almost everyone scrolls straight past on the way to the scarier text underneath. Incompatible mods found! itself only means Fabric Loader read your mods folder, found a mod asking for something that isn't there, and quit before Minecraft ever started. The cause is Fabric API not being installed far more often than anything else, because Fabric API is a separate download and the installer never mentions it. Past that it's usually a loader too old for one of your mods, or jars built for a different Minecraft version than the instance you launched. Two copies of the same mod left behind by an update will do it too. All of it is local — the game dies at startup, so nothing has connected to a server and no admin on the other end can help you.

Read the whole block, and don't go to crash-reports/

The official launcher's output box truncates long errors, and the part that falls off the bottom is usually the solution section — which is why so many people come away convinced the message was useless. It wasn't; you only saw half of it.

The reflex for any Minecraft crash is to open crash-reports/. Skip it here. This error fires while Fabric Loader is still resolving dependencies, before Minecraft's main class runs, so the game's crash-report handler doesn't exist yet and no report gets written. That folder will be empty or holding something old. The block lives in logs/latest.log inside the instance you actually launched:

• Windows: %appdata%\.minecraft\logs\latest.log
• macOS: ~/Library/Application Support/minecraft/logs/latest.log
• Linux: ~/.minecraft/logs/latest.log

Open it, search for Incompatible mods found!, and copy everything from that line down past More details:. Do that before you relaunch to retry. latest.log is overwritten on every launch, and the run you want gets rotated into a gzipped file named for the date, like logs/2026-07-15-1.log.gz.

The solution section is the answer

Here's the shortest realistic version of the block:

net.fabricmc.loader.impl.FormattedException: Some of your mods are incompatible with the game or each other!
A potential solution has been determined:
	 - Install fabric-api, any version.
More details:
	 - Mod 'Mod Menu' (modmenu) 12.0.2 requires any version of fabric-api, which is missing!

A potential solution has been determined: tells you what to do. More details: tells you why. Read them in that order, which is the opposite of what most people do — the details block looks more serious, so that's the part that gets pasted into a search engine while the answer sits two lines above it. The loader has already done the diagnosis, and when it names a version to install or a jar to remove, it means precisely that.

The one thing that makes the block hard to read is that not everything it names is a mod you can download.

What the line names	What it actually is	Where the fix lives
fabric-api	Fabric API — a separate download, not part of the loader	your mods folder
fabric	legacy alias older mods use for Fabric API	same download as above
fabricloader	Fabric Loader itself	re-run the installer
minecraft	pseudo-mod standing in for your game version	the instance
java	pseudo-mod standing in for your Java runtime	the instance's Java settings

A line naming fabric instead of fabric-api isn't a second missing mod. It's the same jar under its old id.

Fabric API is missing

This is number one by a distance, and it isn't your fault. Running fabric-installer-1.0.1.jar gives you a working Fabric client with no mods and no API, and nothing in that installer tells you the API exists as a separate thing. Nearly every content mod depends on it. So the first launch after "I installed Fabric" throws a wall of requires any version of fabric-api, which is missing! lines, and the natural conclusion — that the loader install went wrong — is exactly backwards. Reinstalling it installs the loader again and still doesn't install the API.

Download the single Fabric API jar and drop it in the mods folder. Match the + suffix to your game version: fabric-api-<apiversion>+26.1.jar for a 26.1 instance. Grabbing the newest build without looking turns a missing-dependency error into a minecraft version-constraint error, same block, and it reads like the fix failed. You also want the one parent jar and nothing else. Fabric API bundles its submodules inside itself via jar-in-jar, so hand-collecting the individual fabric-* modules just stacks duplicate-mod conflicts on top of the problem you started with. Modrinth and CurseForge both host it — the two sources compared if you want to know which to pull it from.

While you're here: Quilted Fabric API is a different artifact for a different loader. On plain Fabric Loader it won't satisfy a fabric-api dependency, and it produces its own failure.

The loader is too old

If a line names fabricloader and a version you don't have, update the loader. Don't downgrade the mod — that's trading a 60-second fix for running an old build forever.

Loader version is independent of Minecraft version. One loader build serves many game versions, so updating it doesn't touch your mods folder or the version you play on. Re-run the installer, Client tab, set Minecraft Version to the version you're already on, leave Loader Version on latest stable, Install.

Then pick the new profile from the dropdown left of Play. The installer creates a fresh entry named something like fabric-loader-1.0.1-26.1 and leaves your old profile sitting there, still pointing at the old loader. Hitting Play on the old one changes nothing, the same constraint prints again, and you're now certain you already tried this. It's a well-worn dead end. Installing Fabric cleanly covers the full pass.

The mods are built for the other version

A line naming minecraft and a version you're not running means your jars were built for the other one — 26.2 mods dropped into a 26.3 instance, usually, or the reverse after you updated. Same block, different constraint. Protocol numbers have nothing to do with this; 776 and 777 only matter when a connection is attempted, and none is.

Decide which version you actually want and make everything agree. Rebuild on 26.2 to match 26.2 mods, or download the 26.3 build of every jar. Don't mix.

If you fixed this by making a new profile and it still crashes, the fix didn't fail — by default, every profile in the official launcher reads the same .minecraft/mods folder, so a new profile doesn't get a new mods folder along with it. The wrong-version jars are still sitting there and still loading. You can change that: open the installation in the launcher's edit screen, expand More Options, and point Game Directory at a folder of its own, which gives that installation its own mods. Otherwise move the jars out by hand, or move to a launcher where every instance owns its mods folder by default — Prism Launcher and the Modrinth App both work that way.

Two copies of the same mod

If the block names a mod you updated recently, sort the mods folder by name and look for the same mod at two versions. Updating a mod usually adds a file rather than replacing one, because the new version has a different filename — so both jars sit there and both get loaded. Delete the older one.

One rule-out while you're looking: a Forge jar in a Fabric mods folder is a real problem, but a different one. It carries no fabric.mod.json, so Fabric Loader doesn't recognize it as a mod at all — it gets skipped, the mod never loads, and you get no requires X, which is missing! line about it. The crash, when there is one, comes from whatever else expected that mod to be there.

Bisect only when the solution section can't help

If the solution section is empty, or it names a chain of mods rather than one, halve the folder. Move half the jars out and launch: the culprit is in whichever half was loaded when it crashed. Halve that side and repeat. Sixty-four mods resolves in about six launches, not sixty-four.

Keep Fabric API installed in every single round — pull it and everything errors on a fresh wall of missing dependencies, which is no signal at all. And don't bisect before reading the solution section, or you'll spend ten launches rediscovering what line three already told you. In Prism you can tick mods off in the mod list instead of dragging files around; that just renames them to mod.jar.disabled, and the loader only reads files ending in .jar.

If you're on a modpack, stop

Fix it in the launcher. Reinstall or repair the instance, or reselect the correct pack build. Hand-editing a pack's mods folder desynchronizes it from its manifest.json or modrinth.index.json, which breaks the launcher's ability to update or repair it later. Installing a modpack properly walks that route.

This never reached a server

The server has no idea you exist. Fabric Loader failed a dependency check on your own disk and quit, so there was never a connection to reject. If your game launches fine and a server rejects you after you connect, that's a different layer entirely and the missing-mods mismatch is the page for it. Once the game is running again and you want somewhere to put those mods, the live modded server list ranks active modded servers by votes.

FAQ

The solution section says to install a mod I've never heard of. Is that safe?

Yes. Fabric Loader has no network access at that moment and isn't recommending anything — it's reading the depends block inside the fabric.mod.json of a mod you already installed, and quoting the id it found there. Something in your folder declared that dependency itself. The named mod is almost always a library, and the right move is to get it from the same place you got the mod that wants it.

My friend has the same mods folder and his game launches fine.

Then the difference is the instance, not the jars. The java and fabricloader lines are constraints against his machine's runtime and loader build, not against anything in the folder you copied, so identical mods can resolve on his install and fail on yours. If a java line is what you're staring at, fix it in the instance's Java settings. Wrong Java more often shows up as an UnsupportedClassVersionError, though, which is a different message with a different fix.

I did exactly what it said and now I get a different incompatible-mods block.

That's progress, not damage. The loader reports the constraints it can see; satisfying one set lets it get further and find the next. Chained dependencies resolve in rounds, so work the loop and change one thing per launch. If you're four rounds deep with no end in sight, that's the real signal to stop hand-assembling and install the pack through a launcher instead.

Can I just delete the mod named in the error?

Sometimes. If it's a leaf mod nothing else depends on, removing it is legitimate and fast. If it's a library, you'll trade one block for a longer one. The More details: section is what tells you which — read whether other mods reference it before you decide, and if two or three lines all point at the same id, keep it.