Mojang's server jar and Paper are not the same program wearing different clothes. One is a reference implementation that has to match the game exactly, block for block. The other is a fork built for exactly one job: keep that same game correct while doing far less work to get there.
Why vanilla is slow on purpose, not by accident
Mojang's server has one job above all others: be the ground truth for what Minecraft is. Every block, every mob behaviour, every redstone edge case has to match the client exactly, because millions of single-player worlds depend on that correctness. Performance is a secondary concern to a codebase with that responsibility.
That shows up as real cost. Vanilla ticks every loaded entity and block the straightforward way, with no shortcuts that could theoretically change an edge case's outcome. It sends full chunk data to players who have not moved, recalculates things a smarter engine would cache, and processes the world in the order the code was written rather than the order that would be fastest.
What a fork actually changes
| Optimisation | What vanilla does | What Paper-family software does |
|---|---|---|
| Chunk loading | Loads and generates on the main thread, blocking the tick | Moves generation to worker threads; the main thread only ticks what is ready |
| Entity activation range | Every entity thinks every tick, however far from any player | Distant entities skip most of their logic until a player is close enough to matter |
| Redundant packet sends | Resends data players already have | Tracks what each client already knows and skips repeats |
| Async pathfinding and lighting | Computed inline, on the tick thread | Computed off-thread where the vanilla protocol allows it |
| Configuration | A handful of gameplay rules | Hundreds of tunable knobs — mob caps, view distance behaviour, redstone limits — without touching the jar |
The cost on vanilla is not proportional to players — it is proportional to what is loaded: entities, redstone, hoppers, chunks. A vanilla server with three players standing in a large farm can be slower than a Paper server with thirty exploring normally, because Paper is specifically not paying the vanilla price for that farm.
Where Purpur and Pufferfish sit
Paper is the base fork almost everything else builds on: it adds the plugin API and the core performance work, and it stays deliberately close to vanilla behaviour. Purpur forks Paper again and adds more — extra gameplay toggles, further tuning, some behaviour changes that go beyond what Paper is willing to ship by default. Pufferfish forks Paper too, aimed more narrowly at raw tick performance for very large or very busy servers, sometimes at the cost of a rule matching vanilla exactly. None of the three requires plugins to be rewritten for it; they all speak the same Bukkit/Spigot plugin API Paper established.
Picking between them
| You want | Pick |
|---|---|
| The safest, most widely supported base | Paper |
| Extra built-in gameplay options without installing plugins for them | Purpur |
| Maximum tick performance on a heavily loaded server | Pufferfish |
| Full mod compatibility (not just plugins) | None of these — see the note on Forge/Fabric below |
A Paper, Purpur or Pufferfish server reads the same world format vanilla does. Moving between them, or from vanilla to any of them, is a matter of changing which server jar runs — take a backup first as routine, but there is no conversion step for the world itself.
Forge and Fabric solve a different problem — adding new blocks, items and mechanics the vanilla game does not have. Paper-family software solves performance and adds an API for plugins, which run inside the existing game rather than adding new content to it. A modded server has its own performance story, covered separately, and is not «vanilla but slower for the same reason» — the cost there comes from what the mods themselves compute, not from an unoptimised base.
The console banner names Paper, Purpur or Pufferfish (not minecraft_server.jar), and /version in-game reports the same.