Every server.properties Setting Explained (What to Actually Change)

server.properties is a plain key=value text file that sits in your server folder next to the jar, and it controls the world rules and connection settings that don't need a plugin. You'll realistically touch about a dozen of its fifty-odd keys — motd, max-players, difficulty, pvp, the whitelist and view-distance pairs — and leave the rest on their tuned defaults. The catch is that the file only re-reads on a full restart, and three or four keys will quietly wreck an existing world if you flip them without knowing what they do.

How the file works, and the edits that get eaten

The file lives in the server root folder, right alongside server.jar or your Paper jar, and it isn't shipped inside the download. It gets generated automatically the first time the server finishes its initial startup, right around the stop it throws on that first run. If you launched, cleared the stop, and let it boot, the file is there. If you don't see it yet, the server hasn't completed a first launch. Editing server.properties is one step of the larger job covered in how to set up a Paper Minecraft server; this is the deep dive on that one file.

The format is strict but simple. One key=value per line, no spaces around the =, and no quotes on most values. Edit it with a plain text editor like Notepad or nano, never a word processor, because Word and its kind love to insert smart quotes and curly characters that the parser chokes on.

Two behaviors trip people up. First, changes only apply on a full restart. /reload confirm re-reads plugin and datapack configs, but it never touches server.properties, so if you edit max-players and reload, nothing happens. Second, the server rewrites the file every time it shuts down. It reorders the keys alphabetically and strips out any comment lines you added, so don't bother annotating it. And any colon inside a URL value has to be escaped with a backslash, like resource-pack=https\://example.net/pack.zip, or the line is read as broken.

The keys you'll actually change

Here's the working set almost every owner touches, with the real default and why you'd change it:

• motd=A Minecraft Server — the line shown under your server in the multiplayer list. Supports color codes (the section-sign formatting), so this is where your server name and tagline go.
• max-players=20 — the connection cap. Raise it to what your RAM and CPU can actually feed; the number itself costs nothing until players show up.
• difficulty=easy — one of peaceful, easy, normal, hard. Leave it on easy or bump to normal. Avoid peaceful unless you mean it, and I'll come back to why in the danger section.
• pvp=true — turn it false for a build or co-op server where you don't want players hitting each other.
• gamemode=survival plus force-gamemode=false — gamemode is the mode new players spawn into. force-gamemode reapplies that default mode to everyone on every join, which will yank a creative-mode builder back to survival each time they log in, so leave it false unless that's exactly what you want.
• white-list=false plus enforce-whitelist=false — the on/off toggle for the allowlist. Since 26.3, a newly generated file starts with white-list=true instead, so a fresh server turns everyone away with "You are not white-listed on this server!" until you add them or set it to false. Turning it on and managing names is its own topic; see whitelist a Minecraft server the right way.
• view-distance=10 and simulation-distance=10 — both measured in chunks, and both worth understanding before you drop them to fight lag. The split between what renders and what actually ticks is laid out in view distance vs simulation distance.
• spawn-protection=16 — non-ops can't build or break within 16 blocks of world spawn (0,0). This is the usual answer to "why can't my friend place blocks near spawn." Set it to 0 to disable it entirely.
• server-port=25565 — the Java default. You rarely change this; Bedrock's default is 19132 for context, but a Java server stays on 25565 unless you're running several on one machine.
• allow-flight=false — leaving this off is what triggers the "Flying is not enabled on this server" kick when a legit fly plugin or an elytra edge case sends a player airborne. Set it true if you run plugins that grant flight.
• enable-command-block=false — command blocks are off by default. Flipping this on is one of two steps; the full walkthrough is enable command blocks on a Minecraft server.
• op-permission-level=4 — the tier ops get, on a 1 to 4 scale, where 4 is full access. Most single-owner servers leave it at 4. How to actually grant yourself op is covered in op yourself on a Minecraft server.
• pause-when-empty-seconds=60 — a newer key that idles the tick loop after the server sits empty for that many seconds. It's a good default to leave alone; it saves CPU when nobody's on and wakes instantly when someone joins.

The defaults worth leaving alone

Most of the remaining keys look tunable but shouldn't be touched, and the tuned default was already picked for your case. A short list of ones people fiddle with and regret:

• network-compression-threshold=256 — the packet size where compression kicks in. The default is a sane balance; changing it usually costs more than it saves.
• max-tick-time=60000 — the watchdog timeout in milliseconds. Lower it and you tell the server to kill itself mid-lag-spike instead of recovering. Leave it.
• enforce-secure-profile=true — keep it on unless you have a specific, known reason not to.
• sync-chunk-writes=true, entity-broadcast-range-percentage=100, use-native-transport=true, prevent-proxy-connections=false, rate-limit=0 — all fine where they sit.

The rule of thumb: if you don't know what a key does, its default was chosen for your case, and poking it blindly is how you generate a problem you'll spend an evening chasing.

The keys that quietly break a world

A handful of keys don't just misbehave, they damage an existing world or make it look wiped. These are the ones to leave alone unless you fully understand the consequence.

• online-mode=true is the big one. Set it to false and every player's UUID changes, so the server can no longer match anyone to their world/playerdata/<uuid>.dat file. Everyone appears to lose inventory, ender chest, position, and advancements. The old files aren't actually deleted, so flipping it back recovers them, but it looks exactly like a full wipe and it opens you to impersonation. The one legitimate exception is a Geyser/Floodgate crossplay setup, which deliberately manages this; see set up a crossplay server with Geyser and Floodgate.
• level-name=world points the server at a world folder by name. Change it and the server loads a different, empty folder and generates a brand-new world. Your old world isn't gone, it's just no longer the one being loaded.
• level-seed and level-type only affect newly generated chunks. Change either on a world that already exists and you get visible terrain seams where the old chunks meet the new ones.
• allow-nether=true — set it false and the existing Nether stays on disk, but portals stop working, so nobody can reach it.
• hardcore=false — toggle it true and you force difficulty to hard and ban respawns for everyone.
• difficulty=peaceful — as promised, this despawns all hostile mobs and disables hunger damage. Fine for a build server, quietly ruinous for a survival one.

Resource packs, seeds, and the format traps

The resource-pack and seed keys are where the value syntax bites people, so slow down on these. If you want the background on server packs themselves, see what is a server resource pack.

• resource-pack= takes the full URL, with every colon escaped as \: like the earlier example.
• resource-pack-sha1= is the pack's hash. Omit it and clients re-download the pack on every single join instead of caching it, which is slow and annoying for everyone.
• require-resource-pack=false — set it true and any player who declines the pack gets kicked.
• resource-pack-prompt= is the message shown on the accept screen.

For seeds, level-seed= accepts a string (quote it if it has odd characters) and negatives are allowed. level-type= takes minecraft:normal, minecraft:flat, minecraft:large_biomes, or minecraft:amplified. On the version front, 26.2 is the stable Paper target as of September 2026, since Paper's 26.3 builds are still experimental, and the one default that changed in 26.3 is the white-list one above, which only applies to a freshly generated file. You can check what's actually running on the stable target on the live list at /servers/version/26.2, or /servers/version/26.1 for the drop before it.

What's NOT in server.properties (and where it actually lives)

A lot of settings people hunt for in server.properties aren't there at all, which saves real frustration once you know the layout. The operator list lives in ops.json, bans in banned-players.json and banned-ips.json, and the actual whitelisted names in whitelist.json. server.properties only holds the on/off toggle for the whitelist, not the names themselves.

On Paper, the deeper tuning lives in its own configs, not here. Per-world view-distance overrides, mob spawn limits, entity tracking ranges, and timings sit in paper-world-defaults.yml, bukkit.yml, and spigot.yml. The rule is simple: if a setting you're hunting for isn't in server.properties, it's in the Paper configs.

FAQ

Do I have to restart for server.properties changes to take effect?

Yes. /reload confirm re-reads plugin and datapack configs but never touches server.properties, so a reload after editing this file does nothing. The file is read exactly once, at startup, and there's no built-in command to change values like max-players or view-distance on a running server — a plugin can push a few of those through the Bukkit/Paper API in code, but nothing you type into chat or the console does it. Any edit to the file itself needs a full restart to land.

Why did all my players lose their inventories after I changed a setting?

Almost always an online-mode flip, which changed everyone's UUID. Here's how to confirm it: open world/playerdata/ and you'll see two .dat files per player instead of one — the original, plus a fresh one timestamped to the moment they rejoined after the flip. That second file is keyed to an offline UUID, which the server derives from the username as a name-based hash rather than the random one Mojang issues, so it's deterministic and never matches the real account ID. Flip online-mode back to what it was and the server reads the original file again; every inventory returns. Nothing was deleted — you just had two identities pointing at one player.

Can I change the seed of a world that's already generated?

Not with any practical effect on the chunks you've already visited, since level-seed only steers new terrain and you'll just get seams where old meets new. To genuinely reseed, set a fresh level-name so the server builds a new world in a new folder, and keep the old folder archived. That's the only clean way to swap seeds without leaving a visible border across the map.

Where exactly is the server.properties file?

In the server's root folder, the same directory the jar runs from — which on a rented host usually means the file manager or config editor inside your control panel rather than a path you SSH to. One thing worth knowing while you're in there: don't edit the file with the server running. The live process holds its settings in memory and rewrites the whole file on shutdown, so a change you save to disk mid-session gets clobbered when the server stops. Stop it first, edit, then start it back up.