Minecraft 26.3 turns the server whitelist on by default

Key takeaways

• In Minecraft 26.3, the white-list server property now defaults to true.
• A freshly created server will refuse every connection until you add players or turn it off.
• Existing servers are unaffected – their server.properties already has a value written.

The Wilderness Bound changelog gives it a single line under Server Properties, with no explanation attached. It is the kind of one-line change that costs somebody an hour on a Friday night.

What happens now when you make a server

You download the server jar, run it, accept the EULA, run it again, and hand the address to a friend. Under 26.2 they joined. Under 26.3 they get bounced with a message about not being white-listed, and so does everyone else including, quite often, the person who set it up.

Nothing is broken. The file simply generated with white-list=true instead of white-list=false, and a whitelist with nobody on it is a locked door.

Two ways past it

From the server console, add the people who should be there:

• /whitelist add PlayerName – adds one player
• /whitelist list – shows who is currently on it
• /whitelist reload – re-reads whitelist.json after editing it by hand
• /whitelist off – disables the check without clearing the list

Or set white-list=false in server.properties and restart. That returns the old behaviour exactly.

Worth knowing: operators are not automatically exempt. There is a separate enforce-whitelist property, and on a server where you have opped yourself but not whitelisted yourself, the result can be confusing enough that people reinstall.

Existing servers do not change

Defaults only apply when a property is written for the first time. Your server.properties already contains a white-list line with whatever it was set to, and updating the jar does not rewrite it.

So this affects new servers, servers rebuilt from scratch, and anyone whose hosting panel regenerates the config on a version change. That last case is the one to watch – some panels do exactly that.

Why change the default at all

Because the old default was the unsafe one. A server with an open port and no whitelist is reachable by anyone who scans for it, and public server lists are populated partly by automated scanning. The gap between “started a server for three friends” and “found a stranger in my base” has historically been a few hours.

Flipping the default means the unsafe configuration is now a decision somebody makes rather than one they inherit. That is the right way round, and it is a pattern other software has been moving to for years.

The argument against

It adds friction to the most common case – a handful of people who all know each other and were going to let each other in anyway. Every one of those setups now needs an extra step, and the failure message does not tell a first-time host what to do about it.

That is a real cost, and it is the usual trade when a default moves toward safety. It is also a one-time cost per server, against a risk that repeats.

If you were going to use a whitelist anyway

Then this is a small convenience rather than an obstacle. A whitelist with an application step behind it is the cheapest moderation tool available, and what it filters for is intent rather than identity – the people who fill in a form are the people who wanted to be there.

We went through what that process should ask and how to structure roles around it in the piece on whitelists and vetting, and none of it changes with this release.

What to do on a new 26.3 server

1. Start the server once and let it generate server.properties.
2. Decide whitelist or no whitelist before anyone connects.
3. If keeping it on, whitelist yourself first, then test the connection.
4. Write down who is on it. whitelist.json is the record.
5. Prune inactive entries every few months.

Step three is the one people skip, and it is why the first symptom is usually the owner unable to join their own server.

The rest of the first week

The whitelist is the access question. Everything after it – roles, build permissions, what the rules say, what happens when someone breaks them – is the part that decides whether a server survives its first month, and it is better written down before anyone arrives than improvised afterwards.

The first week of a public server covers that sequence. A locked-by-default server is a reasonable place to start it from.

Other server-side notes in 26.3

Realms picked up invite codes and a higher render distance over the summer, both of which reduce setup friction in the opposite direction. If a whitelist and a config file are more administration than you wanted, that is the trade Realms exists to make – and the comparison is in how to choose Minecraft server hosting.

Images: Traverse project gallery on Modrinth.