Tools / Minecraft
Modpack Server Readiness Checker
Paste a Modrinth modpack link (or a modrinth.index.json /
CurseForge manifest.json) and get a dedicated-server verdict:
loader + Minecraft version, the exact Java version, an estimated RAM range with
sized Aikar's flags, which mods are client-only and must be removed,
missing required dependencies, and a downloadable server install manifest.
Honest scope: Modrinth packs are resolved live via the Modrinth API.
CurseForge's API needs a key this tool doesn't have, so a pasted CurseForge
manifest.json gives you loader, versions, Java, and RAM, but not
per-file server/client classification. If your pack is already installed,
use the mods-folder check below instead - it identifies jars by hash and
gets full classification whatever launcher installed them. Nothing is ever guessed.
Or check the pack you already have installed
Point this at a mods/ folder and it identifies every jar by its
SHA-1 hash on Modrinth, which works no matter where the file came from -
CurseForge, ATLauncher, a zip someone sent you, or a pack you assembled yourself.
You get the same full verdict: client-only mods to remove, missing dependencies,
mods built for the wrong loader or the wrong Minecraft version.
Your mods are not uploaded. The hashing happens in this tab and only the 40-character digests and file names are sent. Check your browser's network tab if you want to confirm it.
Why client-only mods crash dedicated servers
A modpack you install in your launcher is built for the client. A dedicated
server runs a stripped jar with no renderer, no sounds, no GUI classes. Shaders
(Iris, Oculus), minimaps, HUD overlays, animation and camera mods reference those
missing classes: on Forge/NeoForge the server typically dies at startup with a
ClassNotFoundException or a "mod is not present on the server" handshake
error, and on Fabric it can crash or quietly break. The fix is always the same -
delete client-only mods from the server's mods/ folder
(players keep them locally). Modrinth packs declare this per file
(env.server: unsupported), which is exactly what this tool reads.
Minecraft version to Java version
The server jar enforces a minimum Java class version - the wrong Java fails before a single mod loads:
| Minecraft | Java required | Typical failure on wrong Java |
|---|---|---|
| ≤ 1.16.5 | Java 8 | newer Java breaks old Forge (module system errors) |
| 1.17.x | Java 16 | UnsupportedClassVersionError on Java 8-15 |
| 1.18 - 1.20.4 | Java 17 | UnsupportedClassVersionError on older Java |
| 1.20.5 - 1.21.11 | Java 21 | UnsupportedClassVersionError on Java 17 |
| 26.1+ (year-based versions) | Java 25 | refuses to start: "requires running the server with Java 25 or above" |
FAQ
Does this download the whole modpack?
For Modrinth links it fetches only the small .mrpack manifest archive from
Modrinth's CDN and reads modrinth.index.json - never the mod jars. Pasted
manifests are analyzed as-is.
What do the four file buckets mean?
Server-required mods go in the server's mods/ folder.
Server-optional ones work either way. Client-only must be
removed server-side. Verify manually means neither the pack manifest nor
Modrinth declares an environment - this tool refuses to guess.
How accurate is the RAM estimate?
It's a sizing heuristic: a base per Minecraft version (2-4 GB) plus roughly 1 GB per 20-40 server-side mods, capped at 16 GB. World size, view distance, and player count move the real number - start at the low end and watch your MSPT.
What are "missing required dependencies"?
Each Modrinth mod version lists the libraries it needs (Fabric API, Architectury, ...). The tool resolves those one level deep and flags any required dependency that isn't in the pack - the loader would otherwise abort at startup.
Why can't it check a CurseForge link directly?
CurseForge requires an approved API key for programmatic access. Rather than pretend,
this tool accepts the pack's manifest.json (inside the zip you downloaded)
and tells you exactly which checks that enables and which it can't do. For an
installed pack the mods-folder check sidesteps the problem entirely.
How does the mods-folder check work without uploading my mods?
Your browser reads each .jar, computes its SHA-1 digest locally, and sends
only the digest plus the file name. Modrinth's /version_files endpoint maps a
hash back to the exact mod version that produced it, which then gives us that project's
real server_side flag, its dependencies, and the loader and Minecraft version
it was built for. Jars that Modrinth does not know (CurseForge exclusives, custom builds)
are reported as unidentified rather than guessed at.
What else does the mods-folder check catch?
Two failures a manifest cannot show: a jar built for a different loader than the rest of the folder (a Fabric mod sitting in a Forge server is silently not loaded, and anything depending on it then fails), and a jar that does not list your Minecraft version as supported, which is the usual cause of a "Mixin apply failed" crash.