Bedrock names and skins on a Geyser server
Floodgate gives every Bedrock player a prefixed name and a UUID of its own, which changes how your plugins and commands see them. This guide covers the prefix, the skins, and what to type.
6 min read · Updated Oct 21, 2026 · By GuavaHost Team
If you have not set the server up yet, start with Set up Geyser and Floodgate for crossplay. This guide picks up afterwards, when Bedrock players are joining and you are trying to op one, ban one, or work out why a permissions plugin cannot find them.
Why a Bedrock name looks different
Your server is a Java server. Java identifies players by a Mojang username and a UUID (a unique 32-character id Mojang issues with the account). A Bedrock player has neither: they have an Xbox gamertag and an Xbox account id.
Floodgate bridges that gap. When a Bedrock player connects, Floodgate hands the server a username built from their gamertag and a UUID built from their Xbox account id. That is why Steve Plays shows up in chat and in /list as .Steve_Plays:
- a prefix (a dot by default) goes in front of the name,
- spaces become underscores, because Java usernames cannot contain spaces.
Both of those are settings, and both are in plugins/floodgate/config.yml on the Files tab.
The prefix, and why it is a dot
username-prefix: "."
replace-spaces: true
A real Java username can only contain letters, numbers and underscores. A dot is not allowed in one, so a name starting with a dot can never collide with a genuine Java account. That is the whole point of the default: it guarantees that .Steve and the Java player Steve are two different players, with two different inventories and two different permission entries.
If you set username-prefix to nothing at all, a Bedrock player called Steve and a Java player called Steve become the same name on your server. That is a mess waiting to happen, and a way for someone to impersonate a Java regular. Keep a prefix, and keep it to one character: Java usernames top out at 16, and the prefix counts against that.
If you do want to change it, change it before you launch. Changing the prefix later changes every Bedrock player's name, so their permission entries, their homes and anything else a plugin filed under the old name stop matching. Edit the file, press Save, and restart the server from the top of your server page.
How plugins see a Bedrock player
Two things are worth knowing when a plugin misbehaves for Bedrock players only:
- The UUID is Floodgate's, not Mojang's. Floodgate derives it from the Xbox account id, and it looks distinctive: a long run of zeros at the front. Any plugin that stores players by UUID handles Bedrock players perfectly well, it just stores a Floodgate UUID.
- Mojang has never heard of them. A plugin that looks a name up against Mojang's account API to check it exists, or to fetch a UUID, will come back empty for a Bedrock player. That is the single most common cause of "this plugin works for Java players but not Bedrock". Usually it shows up as the plugin refusing to accept the name, or treating the player as never having joined.
Most mainstream plugins are fine. If one is not, report it as "does not work with Floodgate players", which is language its developer will recognise. For the bigger picture of what does and does not cross the edition line, read Geyser explained.
Commands: use the prefixed name
In normal commands, use the name exactly as your server shows it, prefix and all:
op .Steve_Plays
deop .Steve_Plays
ban .Steve_Plays
kick .Steve_Plays
gamemode creative .Steve_Plays
The reliable way to get it right is to copy the name out of the Console rather than typing what the player told you their gamertag was. There is more in Op yourself and the admin commands you need and Ban, kick and unban players.
The one exception is the whitelist. A plain whitelist add tries to resolve the name with Mojang, fails, and does nothing useful, so Floodgate ships its own command, used without the prefix:
fwhitelist add Steve_Plays
fwhitelist remove Steve_Plays
Set up a Minecraft whitelist without locking yourself out covers the rest of the whitelist, and Allowlist and whitelist, and what each one does explains the naming.
Permissions
LuckPerms and the other common permissions plugins work with Bedrock players, as long as you feed them the prefixed name:
lp user .Steve_Plays parent set builder
lp user .Steve_Plays permission set essentials.home true
A useful habit on a crossplay server: do your permissions work on groups, never on individual players. Then adding or moving a Bedrock player is one command, and you are not hunting through per-player entries when a gamertag changes. Set up LuckPerms permissions has the group structure worth copying.
If a plugin lets you pick players from a menu rather than typing a name, the prefixed name is what shows in the list. That is not a bug, and stripping the dot is not the fix.
Skins
Geyser does make skins work in both directions, through GeyserMC's own skin handling:
- Java players see the Bedrock player's Bedrock skin. Geyser uploads it so a Java client can display it.
- Bedrock players see Java players' skins, including the basic Steve and Alex defaults.
When it fails, it fails gently. A player whose skin did not upload in time shows as a default skin to Java players, and that usually sorts itself out when they reconnect. Skins with custom geometry (the non-standard shapes Bedrock allows) get approximated, because a Java client only knows the two standard player models.
Capes and similar extras are controlled by the third-party cosmetic options in plugins/Geyser-Spigot/config.yml. They are cosmetic only: turning them off breaks nothing, and turning them on adds a lookup per player.
Resource packs do not cross over. A Java server pack, including one you force with resource-pack in server.properties, never reaches Bedrock players. To give them custom textures you put a Bedrock pack in Geyser's packs folder instead, and Force a resource pack covers the Java half.
Linked accounts
Floodgate's global linking is on by default. A player who owns both editions can link the two accounts through GeyserMC's linking service, and after that they join as the same player with the same name, inventory and permissions on either device. No prefix, no duplicate entry. GeyserMC's documentation has the current steps a player follows, and it is worth pinning for anyone in your community who plays on both.
Common questions
Why does a Bedrock player have a dot before their name?
Floodgate adds that prefix so Bedrock names can never collide with real Java usernames, which are not allowed to contain a dot. It keeps the two players separate in your permissions, your bans and your world data. You can change the character in Floodgate's config, but you should not remove it.
Can I turn the prefix off completely?
You can, by setting username-prefix to nothing, but it is a bad idea. Without it a Bedrock player can take the exact name of a Java regular, which breaks permissions lookups and makes impersonation easy. If you dislike the dot, pick another character that Java names do not allow rather than removing it.
Why can my plugin not find a Bedrock player?
Almost always because the plugin checks the name against Mojang's account service, which has no record of a Bedrock account. Try the prefixed name first, exactly as the console shows it, and if the plugin still refuses the name, that lookup is the reason. The whitelist is the built-in example, which is why Floodgate ships fwhitelist.
Will Java players see a Bedrock player's actual skin?
Yes, in most cases. Geyser uploads the Bedrock skin so Java clients can render it, and a player whose skin has not finished uploading shows as the default skin until they reconnect. Skins with custom shapes get approximated, because the Java client only supports the two standard player models.
Still stuck? Jump into our Discord at discord.gg/GuavaHost and the team will help you out.
- geyser
- floodgate
- crossplay
- bedrock
- usernames
- skins
- minecraft
Host a Minecraft Geyser server From $3.99/mo, with instant setup and DDoS protection.
Still need help? Our team is online 24/7 to answer questions.