Client Side vs Server Side Mods: A Fabric Player's Guide
Client side, server side, and both sides mods explained for Fabric players: what the terms mean, how to tell which a mod is, and the mistakes that happen when a file lands on the wrong side.
On This Page
Every mod page carries a small, easily skipped line about sides, and that line decides whether the file belongs in your game, on a server, in both, or, in the case of a single player world, why the distinction seems to vanish entirely. It is the most consequential vocabulary in multiplayer modding.
The terms describe where the mod's work happens. Client side work is presentation: rendering, interface, sound. Server side work is authority: rules, world state, content. Many mods work both sides of the street, and the library itself is the classic both sides resident.
A working setup in this area rests on:
- Client only: interface, visual, and sound mods
- Server only: administration, rules, and performance tools
- Both sides: content mods adding blocks, items, entities
- Single player runs both sides inside one game
For the foundation this builds on, read the our Fabric API complete guide.
For the companion walkthrough, read the Fabric API Multiplayer Guide.
What the Sides Mean
Your client is the game you see and hear. The server is the authority that decides what is true in the world: positions, inventories, block states. In multiplayer they are separate programs, often on separate continents, which is why a file's side matters there.
In single player, the game runs an internal server alongside the client in one process, which is why both kinds of mods appear to work in the same folder, and why single player experience teaches the distinction so poorly.
The mismatch error is a friend in disguise: it announces a difference precisely instead of letting the world misbehave subtly. When it appears, compare lists rather than retrying, because retrying a mismatch has never once fixed one. Fabric API makes that consistency possible underneath every mod involved.
Telling Which Is Which
Mod pages state the environment they support, usually near the download button or in a dedicated field. Read it before downloading for a server, every time, because assuming is how client only rendering code ends up crashing a headless server at 2 a.m.
A useful heuristic helps when the page is vague: if the mod changes what you see, it is likely client; if it changes what is true, it likely needs the server; if it adds things that exist in the world, it almost certainly needs both.
Shared worlds deserve a written manifest: the exact list, with versions, in a place every player can see. Manifests end the my version works debates by making the agreed setup a document rather than a memory.
When a page is genuinely unclear, its issues and comments usually contain the answer from a server owner who learned it the hard way. Borrow their evening instead of spending yours.
Content Mods Need Both Sides
Anything that adds a block, item, or entity must exist in the server's truth and in the client's rendering, in identical versions. One side without the other produces the famous join refusal, which is the server protecting the world from a client describing things it does not contain.
The library follows the same rule. When content mods requiring it play on a server, the matching build belongs in the server folder too, as the server setup guide details.
Fabric API itself is identical on both sides by design, which is the whole point of a shared library: the support layer agrees perfectly across the connection, so disagreements can be hunted among the mods themselves.
Wrong Side Mistakes
A client only mod on a server typically crashes it at startup, complaining about rendering classes a server does not have. A server only mod on a client is usually harmless dead weight, ignored or idle, which is why the dangerous direction is client code travelling upward.
The cure is the page check plus a staged launch: start the server after each batch of additions, and let a crash name its batch while you still remember adding it.
Sides Summary
Presentation lives on the client, truth lives on the server, content lives on both, and single player hides the whole arrangement inside one process. Hold that model and mod pages become easy to read at a glance.
Before any multiplayer session, audit the two folders against the model. Five minutes of auditing prevents the entire genre of join night failures.
Frequently Asked Questions
What does client side only mean?
The mod only changes presentation, such as interface or visuals, and belongs only in players' games. Putting it on a server can crash the server at startup. That is Fabric API behaving normally.
Why do content mods need to be on both sides?
New blocks, items, and entities must exist in the server's world truth and render on the client, in matching versions. Missing either side prevents joining or playing correctly. Fabric API is designed to work exactly that way.
Does Fabric API go on the server too?
When mods that depend on it run on the server, yes: place the matching build in the server mods folder as well as in each player's folder. In short, Fabric API is doing its job when that happens.
Why did everything work in single player?
Single player runs an internal server inside your game, so both sides live together. The distinction only becomes visible, and important, in real multiplayer. That is the expected behaviour with Fabric API installed.
Conclusion
Client Side vs Server Side Mods comes down to the same discipline as the rest of a healthy Fabric setup: match versions exactly, change one thing at a time, and keep a written record of what you installed.
Follow that discipline and this part of your setup stops producing surprises, leaving the library to do its quiet work underneath the mods you actually play.
