Online-Mode vs Offline-Mode: What the Setting Really Changes

Online-mode is a single line in server.properties — online-mode=true — that tells your server to check every player against Mojang's login servers before letting them in, and you should leave it on. Flip it to false and the server stops verifying who anyone is, so a stranger can log in typing your admin's exact username and walk away with their rank, inventory, and op. That one boolean is the whole difference between "the server knows who you are" and "the server trusts whatever name you typed."

What online-mode does the moment someone connects

When a client connects to an online-mode=true server, the server runs an authentication handshake before the player ever spawns. It contacts the Microsoft/Mojang session servers, confirms the connecting client actually owns the account for that username, and pulls back the account's stable premium UUID. That UUID is a random version-4 identifier tied to the Microsoft account, not to the name, which is the important part: it follows the person even if they change their username later, so their builds and inventory survive a rename.

The same handshake also turns on packet encryption between the client and server. And once the client has authenticated, it holds a Mojang-issued key that it uses to sign its own chat messages; the server just verifies each signature and attributes the message to that confirmed account. Chat signing is a client job, not a server one. There's a separate server.properties line for the requirement side, enforce-secure-profile=true, which is default-true on its own and independent of online-mode. That key is what forces every player to show up with a signed profile, and only online-mode makes a signed profile possible. Online-mode doesn't flip enforce-secure-profile on; it just gives that key something real to check. None of this is something you switch on yourself. online-mode=true is the default in a fresh server jar, so a server you just downloaded and launched is already doing all of it. This is also the server-side half of the trust question players ask from the other direction in is it safe to join public Minecraft servers.

What offline-mode really changes (the UUID is the whole story)

Setting online-mode=false skips the Mojang check entirely. The server never phones home, never confirms the account exists, and never asks for a password, because there is no password in the protocol at all. Instead of pulling a real UUID, it manufactures one from the name: a version-3 (MD5) name-based UUID derived from the literal string OfflinePlayer:<username>. Because that's a plain hash of the text, the same name always produces the same UUID, forever.

State it plainly: in offline mode the username is the identity. There's nothing behind the name, so any client can connect and claim any name, including non-premium ("cracked") clients that never authenticated with Microsoft at all. Everything the server stores keys off that computed UUID. Player data sits at world/playerdata/<uuid>.dat, your LuckPerms group assignments point at the UUID, and Essentials /home locations are stored under it too. Type a name, get a UUID, get whatever data is filed under it.

The impersonation risk, concretely

Here's the scenario end to end. Your op's in-game name is "Steve". Steve has the LuckPerms admin group, a full base, and op. An attacker sets their client username to "Steve" and connects to your offline-mode server. The server computes the offline UUID from OfflinePlayer:Steve, which is byte-for-byte the same UUID your real Steve has, and hands the attacker Steve's playerdata, Steve's inherited LuckPerms admin group, and Steve's op. From there they run /op on their own alt, or just flatten spawn with worldedit. No exploit, no cracked launcher tricks. They typed a name.

The whitelist does not save you here, and this is the part people get wrong. A whitelist in offline mode matches on the name and the offline-derived UUID, both of which an attacker controls. If "Steve" is whitelisted, the attacker calling themselves "Steve" is whitelisted too, by definition. Whitelisting is genuinely useful, but only on top of real authentication, which is exactly why the right way to run a whitelist assumes online-mode=true underneath it. So the point of view here is blunt: offline mode is rarely justified for anything reachable from the open internet, because the door has no lock on it.

The one place offline-mode belongs: behind a proxy

There is one legitimate setup, and it's a proxy network. In a Velocity or BungeeCord setup, the proxy runs online-mode=true and authenticates each player once at the edge. The backend Paper servers behind it run online-mode=false so they accept the already-authenticated connection the proxy forwards to them, along with the real premium UUID the proxy verified. The player is authenticated exactly once, at the front door, and the backends trust the forwarded identity.

If you leave a backend on online-mode=true in this setup, it tries to authenticate a session that the proxy already consumed, and the login fails with "Failed to verify username!" — the same error covered in fix Failed to verify username, just triggered by a misconfigured backend instead of a client problem.

The load-bearing point: switching backends to offline mode did not delete the impersonation risk, it moved it. Anyone who can reach a backend directly can now impersonate freely, because the backend trusts whatever the connection claims. So two things are mandatory. First, firewall the backends so only the proxy's IP can reach them; a backend listening on 25565 open to the internet with offline mode is full internet-facing impersonation again. Second, use secure forwarding so a backend won't trust a connection that didn't come from your proxy. For Velocity, set player-info-forwarding-mode = "modern" in velocity.toml with a forwarding.secret, and match it on Paper in config/paper-global.yml under proxies.velocity with enabled: true, online-mode: true, and the same secret:. BungeeCord uses legacy forwarding (settings.bungeecord: true in spigot.yml), which has no shared secret and is weaker. A backend exposed on 25565 with offline mode and no forwarding secret is not a network, it's an open server with the auth turned off.

Crossplay does not need offline-mode

A common misconception says you have to flip online-mode=false to let Bedrock players in. You don't. With Geyser and Floodgate installed as plugins on your Paper server, your Java players still authenticate normally and online-mode=true stays on. Floodgate handles Bedrock players separately, authenticating them through Xbox Live on their own path, then tags their usernames with a prefix (the default is a single .) so their identities don't collide with Java accounts. Both sides stay authenticated; nothing gets turned off. The full walkthrough is in set up a crossplay server with Geyser and Floodgate.

The one wrinkle: a standalone Geyser proxy (running separately instead of as a plugin) has its own auth-type setting and is a different setup with different tradeoffs. But for the normal plugin install, leave online-mode where it is. And if you're running plugins at all, stay on the newest version Paper marks as stable, and before you move to a new drop, check that Geyser's supported-versions page lists that Java version too, since Geyser has to update for each one.

FAQ

Can cracked (non-premium) players join an online-mode server?

No. With online-mode=true, the server demands a valid Microsoft login during the login handshake, and a client that can't produce one gets kicked at that stage, before it ever reaches the world or loads a chunk. There's no plugin that toggles this on or off, because it isn't a plugin feature — it's the base online-mode setting doing exactly what it's for. If you want cracked clients in, the only lever is turning off the very protection this whole post is about.

The authentication servers are down — should I switch to offline mode to keep playing?

Only as a short stopgap, and flip it back the moment auth recovers. If you must, turn the whitelist on and firewall the port to trusted IPs first, then set online-mode=false, because during an outage you've removed the only thing verifying identities. The catch: while it's flipped, every player's UUID becomes the offline-derived one, so their data desyncs from their real premium UUID for as long as it's off. See fix authentication servers down for the outage playbook before you touch the setting.

Will switching online-mode reset my players' inventories?

Effectively yes. Online UUIDs are random and account-tied, while offline UUIDs are the MD5 of OfflinePlayer:<name>, so the two never match for the same player. When you flip the setting, everyone loads against a UUID the server has no playerdata file for, so each person spawns as a brand-new player with an empty inventory. Carrying data across requires a UUID-remapping or conversion step that rewrites every file and database entry from the old UUID to the new one.

Does offline-mode turn off chat reporting and signed chat?

Yes. On an offline-mode server, clients can't produce signed chat messages at all, because signing needs the Mojang-issued profile key that only the online authentication step hands out. With no signatures, nothing is cryptographically attributable to a verified account, and players lose the ability to file in-game chat reports to Mojang against each other, since a report bundles those signed messages as evidence and there are none to bundle. If your moderation leans on signed chat or the report system, going offline removes it outright.