Minecraft 26.3 Snapshot 2, released June 30, 2026, flips one line in server.properties: white-list now defaults to true instead of false. It’s a one-word changelog entry, but it changes what happens the first time you start a brand-new server, and it’s already generating confused threads from admins who spin up a fresh install and can’t figure out why nobody can connect.
What actually changes
Before 26.3, a freshly generated server.properties had white-list=false. Anyone who knew your IP could join. You opted into a whitelist by explicitly setting it to true and populating whitelist.json.
From 26.3 Snapshot 2 onward, a freshly generated server.properties has white-list=true. This is a default-on-first-generation change, not a forced migration: if you already have a server.properties file from an older version, upgrading the server jar does not silently flip your existing setting. The new default only applies when the file doesn’t exist yet and the server generates one from scratch, which is exactly the situation every brand-new server hits.
The gotcha: empty whitelist means nobody but you can join
This is the part causing the confused posts. If white-list=true and whitelist.json is empty (which it is, on a server nobody has configured yet), only server operators can connect. Server operators bypass the whitelist check entirely in Java Edition; everyone else is rejected outright, with no exception for “friends you meant to add later.” If you spin up a fresh 26.3 server, invite a friend, and they get bounced with no explanation in the client, this is almost certainly why.
Two commands fix it depending on what you actually want:
/whitelist add <player>for each person you want to let in, keeping the whitelist active. This is the intended new default behavior: secure by default, opt-in access./whitelist off, or manually settingwhite-list=falseinserver.propertiesand restarting, if you want the old open-to-anyone behavior back.
Note that enforce-whitelist is a separate setting: it controls whether already-connected players get kicked when the whitelist is reloaded mid-session. It doesn’t affect whether white-list itself defaults to on. Don’t confuse the two when troubleshooting.
Why Mojang made this change
Mojang hasn’t published a detailed rationale beyond the changelog line itself, but the direction is consistent with a broader shift toward secure-by-default server behavior. The previous default (open to anyone who finds your IP) meant every new server was exposed to scanning bots and griefing attempts from the moment it started, unless the admin proactively locked it down. Flipping the default means a server is private until you explicitly open it, rather than public until you explicitly close it. It’s the same logic behind why Admincraft’s moderators tell people running open servers to expect scanning bots within minutes: the previous default optimized for convenience, the new one optimizes for not getting griefed on day one.
If you’re on Docker (itzg/docker-minecraft-server and similar)
If you run your server through the popular itzg/docker-minecraft-server image, this Mojang-level default doesn’t automatically carry over to how the image behaves. The image manages server.properties and whitelist state through its own environment variables (ENABLE_WHITELIST, WHITELIST, WHITELIST_FILE, OVERRIDE_WHITELIST), and whether your container ends up with white-list=true or false depends on what you’ve set for those, not on what version of the vanilla server jar you’re pulling. Check your compose file or environment config directly rather than assuming the new vanilla default applies; a container that has never set ENABLE_WHITELIST explicitly may behave differently than a bare-metal install on the same Minecraft version.
The practical takeaway
If you’re setting up a new server on 26.3 or later and want it open to the public immediately, don’t skip a step: after your first startup, either run /whitelist off or edit server.properties and restart before you share your IP. If you’re fine with (or prefer) an invite-only server, the new default does the work for you. Add players with /whitelist add as you invite them and you’re done.
If you’re troubleshooting “my friend can’t join my new server” on a fresh 26.3+ install, check white-list in server.properties before anything else. It’s the single most likely cause, and it wasn’t a thing you had to check on any prior version.
Debugging something less obvious than a whitelist setting? Paste your Spark report into our analyzer for a free, instant breakdown of what’s actually happening on your server.