← All posts

minecraftserver-managementpaperspigotpurpurcomparison

Spigot vs Paper vs Purpur: What Each Fork Actually Changes in the Jar

Spigot, Paper and Purpur are a chain of forks, each built on the one before. What each jar adds over the last, from spigot.yml and Paper's chunk system to Purpur's gameplay toggles, and how to choose between them.

ChunkPod Team · October 7, 2026 · 8 min read

Spigot vs Paper vs Purpur: What Each Fork Actually Changes in the Jar

Spigot, Paper and Purpur are the three most common server jars in the Bukkit family. They aren't three unrelated options: each one is a fork of the one before it, so the choice is really about how many patches on top of vanilla you're comfortable running.

This post walks through what each fork actually adds compared to the last, and where the tradeoffs sit.

The fork chain

Every Bukkit-family jar starts with the vanilla Minecraft server code. From there:

• CraftBukkit added the Bukkit plugin API to the vanilla server.
• Spigot forked CraftBukkit and added a mix of performance patches and config options.
• Paper forked Spigot and rewrote large parts of it for performance, bug fixes and a wider plugin API.
• Purpur forked Paper and added a long list of gameplay toggles Paper won't accept upstream.

That order matters. When you run Paper, you're also running everything Spigot changed. When you run Purpur, you're running everything Paper and Spigot changed, plus the Purpur patches on top.

What Spigot changes over CraftBukkit

Spigot's main additions are a config file called spigot.yml and a set of knobs you can tune per world inside it.

The changes people notice first:

• Entity activation range. Mobs, animals and other entities only tick fully when a player is close enough. Farther away they run reduced logic. This alone can save a lot of CPU on a busy server with big farms.
• Mob spawn range per world. The mob-spawn-range setting controls how far from a player, in chunks, mobs can spawn in each world.
• View distance per world. Different worlds can have different view distances, which is useful when your nether or end doesn't need to render as far as your overworld.
• Item, arrow and orb despawn rates. How long dropped items, stuck arrows and experience orbs stay in the world before they clean up.
• Save user cache on stop only and similar small IO tweaks.

Spigot still ships with the older bukkit.yml and commands.yml files, since those come from CraftBukkit. Mob spawn limits live in bukkit.yml under spawn-limits, not in spigot.yml. Server admins mostly leave those files alone once they've set spawn limits and command aliases.

Spigot's philosophy is close to vanilla. It tries not to change how blocks or mobs behave, only how much work the server does to track them.

What Paper changes over Spigot

Paper is where the jar starts to look meaningfully different from what Mojang ships. It rewrites parts of the server internals for speed, patches a long list of vanilla bugs and exploits, and adds a much wider plugin API.

The config side:

• Paper splits its config into paper-global.yml for server-wide settings and paper-world-defaults.yml for world defaults, with a per-world paper-world.yml inside each world folder for overrides. Older Paper builds used a single paper.yml file, and some tutorials still reference that. The Paper Config Generator builds both paper-global.yml and paper-world-defaults.yml if you want a starting point.

The internal changes worth knowing about:

• Chunk system. Paper has reworked how chunks load, generate and get sent to players. The result is that a Paper server can usually keep TPS steady with more players and larger view distances than Spigot on the same hardware.
• Anti-xray. Paper has an anti-xray engine built into the jar. In engine mode 1 it hides ores behind stone. In engine mode 2 it swaps real ores for fake ones and only reveals them when a player is close. It costs some CPU, but you don't need a separate plugin.
• Bug and exploit fixes. Paper patches things like item frame lag exploits and a long tail of similar edge cases. Most are on by default, and some can be turned off if your community wants the vanilla behavior back.
• Mob AI throttling. Paper adds finer control over how often mobs run AI checks, target updates and pathfinding. You can trade a little mob intelligence for a lot of TPS.
• spark and /mspt. Paper has deprecated its old Timings system and bundles the spark profiler instead. /spark profiler records where the server is spending its tick time, /spark tps shows TPS and tick durations, and /mspt gives a quick read on milliseconds per tick. That's the first thing you want when TPS starts dropping.
• Adventure API. Paper handles text and chat through the Adventure library. Plugins that target Paper can send hex colors, hover events and click events without wrapping everything in raw JSON.
• Modern proxy support. Velocity's modern forwarding is supported in the Paper config, so you don't need a separate patch to run behind a Velocity proxy safely.

Paper still runs Bukkit and Spigot plugins. The API is a superset, so a plugin written for Spigot works on Paper, but a plugin written against Paper's extra API won't run on Spigot.

This combination is why Paper is the default choice for a lot of plugin servers: closer to vanilla than a modded jar, but with a lot of the sharp edges filed off.

What Purpur changes over Paper

Purpur's whole reason to exist is that Paper is strict about what it will patch. Paper won't add settings that change how the game plays for cosmetic or convenience reasons, and it won't add gameplay toggles that most servers don't need. Purpur will.

Purpur adds one main config file, purpur.yml, plus per-world sections in that file. Everything Paper and Spigot ship with is still there and still works.

The kinds of things Purpur exposes:

• Rideable mobs. You can turn on riding for a long list of mobs that aren't rideable in vanilla, and configure how they move, jump and get controlled. Some servers use this for events, others for staff transport.
• Ender pearl behavior. Cooldown length, damage on landing, whether pearls end up in the ender chest on death, whether they can fit through 1-block gaps, and so on.
• Zombie villager cure time. Fixed values instead of the vanilla random range.
• Bed and respawn anchor explosions. Toggles for whether they explode in the overworld or the end.
• Phantom, pillager patrol and wandering trader spawn tuning. Rates, conditions and whether they spawn at all.
• Enchantment limits. Cap max levels per enchant, allow enchants on items that don't normally take them, and adjust what's compatible with what.
• Small quality-of-life tweaks. Villager brain optimizations, configurable item cooldowns, tweaks to how certain blocks and mobs interact.

Purpur is still Paper underneath, so Paper plugins work. A plugin that uses Purpur-specific API won't run on Paper, but very few plugins do that. Most use Paper's API and let Purpur users benefit from the server config.

Why an admin might stay on Paper

Paper is the target most plugin developers build against, and most public server posts assume. If your community is happy with the vanilla mechanics and you don't want a wall of extra config to read, there's no strong push to move.

Sticking with Paper also means fewer surprises when you update. Purpur follows Paper closely, but adding another fork in the update chain means one more thing that can lag behind on a fresh Minecraft release.

Why an admin might step up to Purpur

The main reason is control. If you've ever wanted to set a fixed ender pearl cooldown for PvP balance, or let players ride mobs that aren't rideable in vanilla, Purpur has a toggle for it. Paper won't add those toggles, so a separate fork is where they end up.

The other reason is that plugin compatibility is usually fine. Purpur doesn't rewrite the plugin API, it extends it, so the plugins you already run keep working.

The tradeoff is config surface. purpur.yml is long, and it's easy to change something and forget you did. Keep a copy of your config in version control if you go this route.

What none of these are

All three are Bukkit-family jars. They run Bukkit, Spigot and Paper plugins, and they don't run Forge or Fabric mods. If you want the mods from your favorite modpack, that's a different jar entirely, and this comparison doesn't apply.

They also all read the same server.properties for the core settings (port, MOTD, online mode, difficulty, gamemode, world name and so on). The fork-specific configs sit on top of that, not in place of it.

Picking without ranking

There isn't a best jar out of the three. Spigot is closer to vanilla and lighter on config. Paper adds a lot of performance and bug-fix work, and it's what most plugins target. Purpur adds gameplay toggles on top of Paper for servers that want to tune the game itself. The Server Software Comparator puts them side by side with other server software if you want a quick overview.

If you're already comfortable in Paper's config, moving to Purpur takes an afternoon of reading. If you're on Spigot, the jump to Paper usually pays off in TPS and API options long before it costs you anything.

ChunkPod is in early access, and there's a waitlist at chunkpod.com if you'd like a spot when hosting opens. The free tools at chunkpod.com/tools, including the server.properties Generator and the JVM Arguments Generator, work with any of the three jars.