Minecraft Whitelist Manager
Add player usernames, automatically fetch their UUIDs from Mojang, and generate a properly formatted whitelist.json file.
Add Players
Embed This Tool
Put the whitelist manager on your own site or server wiki.
<iframe src="https://tools.astroworldmc.com/embed/whitelist-manager" width="700" height="650" frameborder="0" style="border:none;border-radius:12px;" loading="lazy" title="Whitelist Manager"></iframe>
How to build whitelist.json
Paste the names
One username per line, as many as you have, in whatever order they arrived.
Fetch the UUIDs
The tool asks Mojang for the account behind each name and marks the ones that do not resolve.
Check the heads
Each row shows the player head next to the name, so a typo is visible before the file goes on the server.
Copy the file
The output is a JSON array of uuid and name pairs, which is the exact shape whitelist.json takes.
How It Works
Format and manage your whitelist.json.
Names resolved one at a time at the Mojang profile endpointPage updated
How to Use the Whitelist Manager
The whitelist.json file controls which players are allowed to connect to your Minecraft server when whitelisting is enabled in server.properties. Each entry requires both the player username and their UUID (Universally Unique Identifier). The UUID is what Minecraft actually uses to identify players. If you enter the wrong UUID, the player will not be able to join even if their username is listed.
This tool automates the UUID lookup process. Enter one or more player usernames in the text area, either one per line or comma-separated, then click the fetch button. The tool queries the Mojang API to resolve each username to its official UUID. Successfully resolved players show a green dot and their player avatar. Names that could not be found show a red dot. The file only bites once white-list is true in server.properties, which the server.properties generator writes for you.
Common Use Cases
Private servers and SMP communities that want to restrict access to a known list of players use whitelisting. Instead of adding players one at a time with the /whitelist add command in-game, this tool lets you build the entire list at once from a roster of names. This is especially useful before a server launch when you have a list of accepted players from an application form.
The generated whitelist.json follows the exact format Minecraft expects. Download the file and place it in your server root directory alongside server.properties. Make sure white-list is set to true in your server.properties and restart or run /whitelist reload. The server will then only allow listed players to connect. Each entry needs the UUID that belongs to the name, which the UUID lookup resolves from Mojang, and what those players may do once they are in is a separate file that the permissions calculator writes.
A Released Name Can Belong To Someone Else
Resolving a name returns the account holding it today. Names that are given up go back into circulation, so a list pasted out of a thread from months ago does not simply fail on the ones that moved: an entry can quietly resolve to a stranger who picked the name up in the meantime. Names worth doubting are worth checking one at a time before a list built from chat messages goes near a live server.
A Whitelist Is Not A Firewall
It decides who may finish a login, and nothing more. The port stays open, every bot scanning for Minecraft servers still finds it, and the server still answers the server list with its version, MOTD and player count, which is what the server status checker reads back. It is not a permission system either: a player who gets through the door has whatever their group already gave them.
Bedrock Keeps Its Own List
This page writes the Java file. A Bedrock dedicated server keeps allowlist.json instead, built around the Xbox account rather than a Mojang UUID, so the two are not interchangeable and a Java whitelist dropped onto a Bedrock server matches nobody.
How the server reads whitelist.json
| File | whitelist.json in the server root, beside server.properties. A JSON array of objects with a uuid and a name. |
|---|---|
| Switch | white-list=true in server.properties. Without it the file sits there and does nothing. |
| enforce-whitelist | true kicks players who are online and not on the list as soon as it is reloaded. false lets them stay until they log out. |
| Reload | /whitelist reload reads the file again with no restart. |
| Operators | Operator status bypasses the whitelist, so an op joins whether or not the file mentions them. |
| ops.json | A separate file for a separate job. Adding someone to the whitelist gives them no permissions at all. |
An offline mode server does not ask Mojang for a UUID, it derives a version 3 UUID from the bytes of OfflinePlayer: plus the name. Those UUIDs change the moment the player changes name, and they never match the Mojang UUIDs this tool fetches. Only use the output here on a server with online-mode=true.
Each name you paste is resolved one at a time at the Mojang profile endpoint api.mojang.com/users/profiles/minecraft, so the UUID beside it is the one Mojang hands out today. Nothing here derives a UUID from the letters of a name, because a name does not contain one.
Frequently Asked Questions
Questions about whitelisting
Is the name enough, or does the server need the UUID?
Both fields are written, but the server matches on the UUID. An entry with the right name and a wrong UUID does not let the player in, and an entry with the right UUID keeps working after a name change.
Why is a removed player still online?
Removing an entry disconnects nobody. Set enforce-whitelist=true and run /whitelist reload, or kick them by hand.
Can an operator join a whitelisted server?
Yes. Operator status bypasses the whitelist check completely, which is also why an op should never be the only way back into a server.
Does this work on a cracked or offline server?
The file format is identical, the UUIDs are not. Offline mode generates its own UUID from the player name, so a Mojang UUID matches no account on that server.
