“Found a duplicate mod” and DuplicateModsFoundException on a Minecraft server: finding the second copy
Two jars in your mods folder declare the same mod id, and the loader will not pick one for you. This crash is the cheapest one on this site to fix — the log names the id and, on most versions, both files — and it is almost always the leftover from an update that added a new jar without removing the old one.
What the error means
Every mod declares a mod id in its metadata, and the loader requires that id to be unique across the mods folder. Two jars claiming the same id could be two versions of one mod, or two different mods that happen to bundle the same library. The loader cannot know which, so it refuses to start rather than load one at random and leave the other half-registered.
Minecraft never started, so the world is untouched. The fix is removing one file.
The wordings
| What the log says | Where | What it gives you |
|---|---|---|
| Found a duplicate mod <id> at [a.jar, b.jar] | Modern Forge and NeoForge console | The id and both filenames — everything you need. |
| DuplicateModsFoundException | The exception name in the stack trace, any version | Confirmation of the class of failure; look above it for the id. |
| Duplicate Mods: followed by lines of <id> : <path> | The crash report on legacy Forge (1.12.2 and earlier) | The id and the full path of every jar involved, including jars in a version subfolder such as mods/1.12.2/. |
| Contained version … for mod … conflicts with | Forge and NeoForge, jar-in-jar libraries | Two mods bundle the same library at different versions — the conflict is inside the jars, not between two copies of one mod. |
How the second copy usually gets there
- A manual update. You dropped in the new version and the old jar is still sitting beside it, often under a slightly different filename.
- A pack update applied over an old install rather than into a clean folder. The updater added the new jars; nobody removed the ones it replaced.
- A subfolder the loader also scans. Legacy Forge reads mods/<minecraft-version>/ as well as mods/, so a jar in each is two copies even though one folder looks empty.
- A jar renamed to a new name after the original copy was uploaded again by the launcher or a sync tool.
- Two different mods that each bundle the same library. This is the jar-in-jar wording above, and it is the one case where removing a file is not the fix.
How to fix it
- Take the mod id from the log. On modern loaders the line already names both files; on legacy Forge, read the Duplicate Mods: block in the crash report for the paths.
- If only the id is named, sort the mods folder by name and look for two jars whose names share the mod's name. Check version subfolders too.
- Keep the newer version and remove the other. If the filenames do not carry a version, the larger file is usually the newer build — but open the jar's metadata if you are not sure.
- Restart. A pack that was updated in place may surface a second duplicate on the next boot; repeat.
- For the jar-in-jar wording, the fix is to update the two mods that bundle the conflicting library so they agree, or drop one of them. Removing either jar's bundled library by hand is not supported and will crash later.
On Fabric the same mistake prints a different message: a Non-unique Mixin config name shared by two mods.
Read the Fabric guideWhat MineXHost's launcher does with this crash
MineXEngine reads the loader's own list — the Found a duplicate mod line, or the Duplicate Mods: block in a legacy crash report — and acts on the files the loader printed rather than on a guess from the mod's name. It keeps the largest file and moves the other copy into mods/.quarantined/, then restarts. The copy is moved, not deleted, so you can put it back.
This is the one crash where the engine does move a file on a customer server without asking first. The reasoning is that a duplicate copy is not your mod — the mod is still there, in the copy that stays — and there is no other recovery. Everywhere else, crash recovery on your server identifies a culprit and leaves mods/ alone.
Two guards keep that honest. A second jar whose own metadata declares a mod id the kept jar does not provide is treated as a different mod and spared, so an add-on that shares its parent's id is never removed as a duplicate. And when the loader says duplicate but the engine cannot anchor a real mod id in the text, it refuses to guess: an early engine once matched a fragment of the exception message against unrelated filenames, and that is the mistake this guard exists to prevent.
MineXHost runs Forge, NeoForge and Fabric packs on MineXEngine — our launcher auto-detects the modpack, picks the right Minecraft loader and Java version, tunes the JVM for your RAM, and auto-recovers from the crashes that normally end a modded server's evening. Pick your RAM, paste the pack, and play.
See hosting plansFrequently asked questions
What does “Found a duplicate mod” mean on a Minecraft server?
Found a duplicate mod means two jar files in the mods folder declare the same mod id, and Forge or NeoForge refuses to start rather than choose between them. The line names the id and, on modern loaders, both filenames in brackets. In nearly every case the two files are two versions of one mod left behind by an update, so keep the newer one and remove the other. Minecraft never started, so the world is unaffected.
How do I find the duplicate mod if the log only gives the mod id?
Sort the mods folder by name and look for two jars that share the mod's name with different version numbers or suffixes, then check any version subfolder such as mods/1.12.2/, which legacy Forge scans as well. On legacy versions the crash report under crash-reports/ carries a Duplicate Mods: block that prints the full path of every jar involved, which is faster than searching. If the names do not show a version, the larger jar is usually the newer build.
Which of the two copies should I delete?
Keep the newer version and remove the older one, and when the filenames do not make that obvious, the larger file is usually the newer build. Move the removed jar somewhere outside the server folder rather than deleting it, so you can swap back if the pack turns out to have wanted the other version. If the two jars are visibly different mods that merely share an id — an add-on and the mod it extends — do not remove either; update both instead.
Does MineXHost remove the duplicate for me?
Yes, and this is the one crash where MineXEngine moves a file on your server without asking: it reads the two paths the loader printed, keeps the largest copy, moves the other into mods/.quarantined/ and restarts. The file is moved, not deleted, so it can be restored. A second jar whose own metadata declares an id the kept copy lacks is treated as a different mod and left alone, and if the engine cannot find a real mod id in the message it refuses to guess rather than touch the wrong file.
What is “Contained version … conflicts with” on Forge?
A contained-version conflict means two mods each bundle a copy of the same library inside their own jar, at versions the loader cannot reconcile, which is a different problem from two copies of one mod even though it prints a similar exception. There is no duplicate file to remove. Update the two mods named until they agree on the library version, or drop one of them; editing the library out of a mod's jar by hand is unsupported and fails later.