OP & whitelist

Two different tools, often confused. OP decides who can run admin commands on your server. Whitelist decides who can even join in the first place. This guide covers both — how to set them up, the OP levels nobody talks about, and the offline-mode gotcha that locks half the internet out by accident.

Minecraft Last updated May 19, 2026 ~7 min read

OP vs whitelist — the difference

It comes up in every support ticket, so let's settle it up front:

You can mix them in any combination: whitelist-only with no ops (locked private server, no admin), whitelist + ops (private server with admins), no whitelist + ops (public server with admins), or no whitelist + no ops (anarchy).

Granting OP

The fastest way is from the console. Open the dashboard, scroll to the console, and type:

console 
> op Steve
[Server] Made Steve a server operator

Steve is now an op. They'll keep that status across reconnects, restarts and crashes — it's persisted to ops.json at the server root.

Console = automatic OP-level 4

Commands typed from the panel console run with the highest possible permissions. You don't need to op yourself first — you already are, as far as the server is concerned. op Steve just adds Steve to the persistent list.

OP levels — the part nobody reads

Vanilla Minecraft has four operator levels. The level controls how much an op can actually do:

The default level is set in server.properties:

server.properties 
op-permission-level=4

For a public SMP, dropping the default to 2 and saving 4 for yourself (by editing ops.json manually) is a sensible safety measure — moderators can still teleport and give items, but only you can /stop the server.

Editing ops.json directly

Open Files → ops.json. It looks like this:

ops.json 
[
  {
    "uuid": "069a79f4-44e9-4726-a5be-fca90e38aaf5",
    "name": "Notch",
    "level": 4,
    "bypassesPlayerLimit": false
  },
  {
    "uuid": "853c80ef-3c37-49fd-aa49-938b674adae6",
    "name": "Steve",
    "level": 2,
    "bypassesPlayerLimit": false
  }
]

To bump someone's level or let them bypass max-players, edit the JSON and restart. Make sure to stop the server first — Minecraft rewrites this file on shutdown and your edits will be lost otherwise.

Removing OP

Two ways — either is fine:

console 
> deop Steve
[Server] Made Steve no longer a server operator

Or stop the server, delete the offender's entry from ops.json, save, start the server. Same result.

Whitelist basics

Whitelist mode locks the server to a guest list. Great for friends-only SMPs, private modded worlds, or anywhere you don't want random scanners poking around.

Two prerequisites and the rest is easy:

  1. Add every player you want to allow.
  2. Turn whitelist on.

Doing it the other way around — turning it on first and then trying to add players — works, but anyone who tries to log in during that gap gets booted.

Enabling the whitelist

From the console:

console 
> whitelist on
[Server] Whitelist is now turned on

Or edit server.properties:

server.properties 
white-list=true
enforce-whitelist=true

The enforce-whitelist setting is the important one. Without it, removing a player from the whitelist only affects their next login — they stay connected this session. With it on, they get kicked the instant you remove them. For most use cases, leave it on.

Adding & removing players

From the console:

console 
> whitelist add Notch
[Server] Added Notch to the whitelist

> whitelist remove Notch
[Server] Removed Notch from the whitelist

> whitelist list
[Server] There are 4 whitelisted players: Notch, Steve, Alex, Herobrine

Names are case-insensitive but spelling counts. The server resolves the name to a UUID via Mojang's API when you add them — if Mojang is down, the add will fail with "That player does not exist". Wait a minute and retry.

Whitelist file structure

whitelist.json sits next to ops.json and looks similar:

whitelist.json 
[
  {
    "uuid": "069a79f4-44e9-4726-a5be-fca90e38aaf5",
    "name": "Notch"
  },
  {
    "uuid": "853c80ef-3c37-49fd-aa49-938b674adae6",
    "name": "Steve"
  }
]

You can bulk-edit this file directly. Same rule as ops.json: stop the server first or your changes get overwritten.

The offline-mode gotcha

By default the server runs in online mode — every joining player is verified against Mojang's auth servers, and their UUID is the real one tied to their account. Setting online-mode=false (offline mode) gives every player a UUID derived from their username, which means:

Stay in online mode

Don't flip online-mode=false unless you really know why. It's the single most common cause of "I added myself to the whitelist but I'm still getting kicked." Cracked clients won't work on PulsarServers regardless — the only legitimate reason for offline mode is running a Velocity/BungeeCord proxy in front of the server, and in that case the proxy enforces auth instead.

Bedrock players (Geyser / Floodgate)

Bedrock accounts have an XUID, not a Mojang UUID — and they often have a . prefix in their name (e.g. .SteveBE) added by Floodgate. Two things to know:

Customising the kick message

By default rejected players see "You are not white-listed on this server!" — fine, but not friendly. Override it with a plugin like Whitelister or edit your proxy's reject template. Vanilla servers don't expose the message directly.

Common issues

Still stuck? Open a ticket with the relevant console lines plus the contents of ops.json or whitelist.json and we'll dig in.