How to Op Yourself on a Minecraft Server

To op yourself you grant operator status with the op command: from the server console type op YourUsername with no leading slash, or run /op YourUsername in game if you already have operator powers. Which one you use depends entirely on the situation. On a brand-new server where nobody is op yet, you can't op yourself in game because the command needs powers you don't have yet, so the first op always comes from the console (or by editing a file directly). Once someone is op, that person can promote anyone else in game with a normal chat command.

You'll also need to own and be signed into Minecraft on the account you want to op, since the server has to match your username to your account when it joins.

This guide is Java Edition focused, where operators live in a file called ops.json. Bedrock works a little differently, and there's a note on that down in the FAQ.

Opping from the server console (the first op)

A fresh server has no operators at all. Because the in-game /op command requires operator-level powers to run, nobody on the server can use it yet, including you. The way around this is the console, which always runs commands at the highest permission level, level 4. The console doesn't need to be op because it effectively is the server.

Open your host panel's console tab or your terminal window, and type the op command without the leading slash:

op YourUsername

The slash is only for in-game chat. In the console you drop it. Spell your username exactly the way it appears on your account, because the server has to resolve that name to a player. In online mode it looks up your real UUID through Mojang; in offline mode it derives a UUID from the name itself, which is why case and spelling matter even more there. The server replies with a confirmation that names the player it opped, and it writes that player straight into ops.json for you. No file editing, no restart.

If the panel console isn't responding for some reason, you have a fallback: stop the server and add yourself to ops.json by hand. More on the exact shape of that file below.

Using /op in game (once you already have it)

Once you hold operator status, you don't need to go back to the console to promote anyone. You can run the op command right in chat:

/op Teammate

The slash version needs permission level 3 or higher, which in practice means you have to already be op. That's the whole reason the first op can't come from in game. After that first one exists, though, in-game opping is the easy path. It applies instantly, saves to ops.json live, and needs no restart. To take operator status back off someone, use /deop Teammate, which is just the reverse.

How ops.json actually works

ops.json sits in the server's root folder, right next to server.properties and whitelist.json. If you've followed a Paper server setup before, you've seen this folder, it's the same directory where your world folders and config files live. This one file is the source of truth for who counts as an operator.

Each operator is one entry with four fields:

• uuid — the player's unique ID, written as hyphenated hexadecimal.
• name — the username, mostly there so the file is readable by humans.
• level — the operator's permission level, 1 to 4.
• bypassesPlayerLimit — whether this player can join when the server is already full.

That last field is worth understanding because it's easy to misread. If it's set to true, the player can join even when max-players has already been hit, but they still count toward the player limit once they're on.

When you run the op command, the server writes the new entry using whatever default level is set by op-permission-level in server.properties. Editing the file by hand is perfectly valid, but the catch is that the server only reads ops.json at startup, so a manual edit won't take effect until you restart or reload. The op command is the safer habit for two reasons: it applies immediately, and it can't introduce a JSON typo that corrupts the whole file and silently wipes out every operator.

op-permission-level: the 1-4 tiers and what each unlocks

op-permission-level in server.properties controls the default level a newly opped player receives. Its default value is 4, and the valid range is 0 to 4. The levels are incremental, so each one includes everything the level below it can do, then adds more on top.

• Level 1 (Moderator) — can bypass spawn protection. That means placing and breaking blocks, and using buttons and levers, in the protected zone around world spawn.
• Level 2 (Gamemaster) — can run the singleplayer cheat commands, and this is the minimum level needed to edit command blocks.
• Level 3 (Admin) — everything in level 2, plus the power to affect other players directly: kick, ban, and op or deop people.
• Level 4 (Owner) — every server command, including /stop and restart-level control.

One thing that trips people up: changing op-permission-level only affects players opped after the change. It sets the level new ops are created with at the moment of promotion. It does not reach back and rewrite the level stored on existing ops.json entries. If you want to bump an existing operator up or down, edit that entry's level field in the file directly (and restart so it's read).

Keep your op list tiny

Op is close to all-or-nothing, and this is the part most new owners underestimate. On Bukkit, Spigot, and Paper, being op grants every permission node that a plugin registered with a default of "op", and for most plugins that covers essentially all of their admin and destructive commands. So the moment you op someone, you're not just handing them the vanilla command set. You're quietly handing them admin powers across every plugin you've installed.

That matters for two reasons. First, a blanket op overrides any careful staff ranks you set up, because the op flag sweeps in permissions your ranks were deliberately scoped to exclude. Second, an op can /stop the server, ban players, and run worldedit-style commands that flatten terrain in seconds. There's no partial trust here.

So the rule is simple: only the owner and a small number of fully-trusted admins should be true ops. Everyone else gets scoped permissions instead, which I'll get to next. The reason is simple — fewer ops means less to clean up if an op account gets compromised, or if a staffer you trusted turns out to be a bad call. Pair a short op list with a whitelist and a small private server becomes genuinely hard to wreck.

Grant staff powers through LuckPerms instead of a blanket op

For moderators and helpers, you almost never want op. You want a permission plugin so you can grant exactly the commands the role needs, like /kick and /mute, without also handing over /stop or the ability to delete the world. A permissions plugin is one of the first things worth installing on a new server for exactly this reason.

There's also a subtle predictability win. An op does not receive the literal * wildcard permission, so an op can actually miss a permission that you've explicitly set elsewhere. Ranks behave more consistently than op because you're stating, node by node, what the role can and can't do, instead of relying on each plugin's idea of what "op" should mean.

The clean approach is named ranks with inheritance, something like Helper, Mod, and Admin, where each one builds on the one below. Setting that up in LuckPerms takes a few minutes and it's what gives you real staff tiers. LuckPerms does have a luckperms.autoop option that can auto-grant op to a whole group, but I'd steer away from it for anyone but top-level admins. A tightly-scoped rank does the same job with far less risk.

Removing op and troubleshooting

To take operator status away, use /deop Player in game, or deop Player (no slash) in the console. It removes or updates that player's ops.json entry, the exact inverse of the op command.

A few snags come up often:

• /op says you don't have permission. You aren't op yet. The command needs level 3+, and on a fresh server that means nobody can run it. Go to the console, which is level 4, and grant the first op from there.
• A hand edit to ops.json didn't take. The server hadn't reloaded, so it never read your change. Restart it, or just use the op command instead and skip the problem.
• You opped a misspelled name. That creates a dead entry pointing at a player who doesn't exist. Remove it and re-op the exact, correctly-spelled username.

FAQ

Does opping work the same on an offline-mode (cracked) server?

The mechanic is the same, but the UUIDs are generated differently. In online mode the server fetches the real Mojang UUID for the name; in offline mode it generates a UUID from the username itself, so the name has to match exactly, case included. If you later switch the server between online and offline mode, the UUIDs stored in ops.json may no longer match the players who join, and you'll need to re-op.

Is opping the same on a Bedrock server?

The concept carries over but the files don't. On a Bedrock Dedicated Server you grant operator status by gamertag, and the operator, member, and visitor tiers are managed through the server's permissions config rather than a Java-style ops.json with a 1-4 level. Most hosting panels give you a simple op toggle in the UI, but the underlying file and permission model are Bedrock-specific, so don't expect op-permission-level or the level tiers to appear there.