Minecraft Java and Bedrock Crossplay: The Geyser and Floodgate Setup Guide

Mojang's answer to "can Java and Bedrock players play together" is no. The two editions run on different servers, and a Bedrock client has no way to speak to a Java one.

There is a way around it. Java and Bedrock players can share one world when the Java server runs Geyser to translate Bedrock's protocol and Floodgate to handle Bedrock logins. This guide covers the manual setup on Paper, Fabric and NeoForge, the limitations to expect, and the fixes for the errors that come up most.

What Geyser and Floodgate actually do

Geyser sits between a Bedrock client and a Java server and translates in both directions. It emulates a Java client, so your server sees a Bedrock player as an ordinary Java player — plugins, datapacks and worldgen all apply to them without knowing the difference.

Floodgate solves the other half. Geyser on its own still expects every Bedrock player to own a paid Java Edition account. Floodgate removes that requirement, so your friends sign in with the Microsoft account already on their console or phone. Both projects come from GeyserMC, which states plainly that it is not associated with Mojang or Microsoft.

The catch is that this is a build, not a setting. You are matching two jars to your exact Minecraft version, editing config files, opening a UDP port that some hosts do not offer at all, and re-checking the whole chain every time Minecraft updates.

That is why on Pixly it is one switch: turn on Bedrock cross-play in Settings and restart. If that is what you were after, Java and Bedrock crossplay hosting covers it and you can stop reading here.

Where Java and Bedrock crossplay falls short

Read this part before you install anything. Geyser is a translator, and some things have no translation.

Effects and mechanics that do not cross over

GeyserMC maintains a current limitations list. The items most likely to affect a real server:

• Custom enchantments and sweeping edge, and non-vanilla enchantment levels
• Custom anvil, smithing and furnace recipes, and custom beacon base blocks
• Bedrock inventories cannot distinguish a left click from a right click
• Command arguments only translate for commands built on Brigadier
• Clickable links in chat, and anything depending on tab-completion
• The glowing effect, potion colors set through the PotionContents data component, and invisible item frames
• Heights below -512 or above 512 in the overworld — and, far more restrictive, below 0 or above 256 in the Nether and End

The full list is longer and worth skimming before you commit. Some of the visual gap — armor stand poses, illusioners, hit particles, offhand animations, shulker invisibility, spectral arrows — is already patched by the Bedrock resource pack Geyser ships with, GeyserIntegratedPack.

Your server listing changes too. Geyser relays the Java MOTD to Bedrock by default, but Bedrock renders less of it: custom hex colors fall back to the nearest of the 16 built-in ones, underline and strikethrough drop away, and a literal semicolon corrupts the message — everything after it can vanish. Our Minecraft MOTD generator previews the Java rendering and flags each of those as you type.

Bedrock names arrive changed

Floodgate prefixes Bedrock usernames with a dot and replaces spaces with underscores, so a Bedrock player called Steve Miner joins as .Steve_Miner. Both behaviors are configurable (username-prefix and replace-spaces), but the prefix exists to stop a Bedrock player colliding with a Java player of the same name — think before you remove it. Whitelist entries, permission nodes and any command a Java player types from memory need the prefixed name.

Java resource packs do not convert

A Java resource pack will not work on Bedrock as-is. Geyser's FAQ points to a third-party converter, but with a real catch: it only handles packs up to 1.17, so on a current server you are converting by hand or going without. Converted packs go in Geyser's packs folder and are sent to Bedrock players automatically.

Mods stay Java-first

Geyser only works with server-side mods. The rule of thumb from the FAQ is "if a vanilla client can join the server, then so can Geyser" — a server that requires a client-side install is not something Geyser can join. Server-side mods, plugins and datapacks apply to everybody equally, but GeyserMC is explicit that there is no way to translate the blocks, items and mobs most mods add. Heavily custom packs are a Java-side experience.

Cross-platform play on consoles needs a workaround

Xbox, PlayStation and Switch give players no field for a custom server address, only a curated Featured Servers list. GeyserMC documents the ways around this in using Geyser with consoles: a DNS service called BedrockConnect, or a LAN-proxy companion app such as BedrockTogether or MCCompanion. None of these are affiliated with GeyserMC, and the main BedrockConnect IP is often blocked on consoles, so expect to try an alternative from their list. Phone, tablet and Windows players just add the address.

A few plugins conflict with Floodgate

Floodgate modifies the login process, so the FAQ flags DynamicBungeeAuth (below 10.28B), FastLogin, ExploitFixer, JPremium, LibHatesMods, ProtocolSupportBungee and SayNoToMcLeaks. TCPShield is a separate case — it needs only-allow-proxy-connections disabled, which its paid plan handles. Note that ProtocolSupport used to be on this list and no longer is; GeyserMC now says it works, though it recommends ViaBackwards instead.

Before you start: what has to line up

Three things decide whether this will work at all, and it is much cheaper to check them now than after two restarts.

Server software that accepts plugins or mods. Geyser installs as a plugin on Paper, Spigot and their forks, as a mod on Fabric and NeoForge, and as a proxy plugin on Velocity and BungeeCord. Vanilla has no loader to put it in, and there is no Forge or Quilt build. That is not a dead end — Geyser Standalone runs as its own proxy process in front of any Java server, including Forge — but it is a different setup, covered at the end.

A Minecraft version Geyser has been taught. Geyser emulates one specific Java version at a time. At the time of writing it supports Minecraft Java 26.2 and Bedrock 26.0–26.40; check supported versions before downloading, because that page moves. Two hard boundaries live there:

• Geyser-Spigot needs a server on 1.20.5 or above. Below that the plugin is not an option at all — the wiki's words are "this is unfortunately not possible". You need a proxy, or Geyser Standalone alongside ViaVersion, or ViaProxy.
• Geyser-Fabric and Geyser-NeoForge only run on the latest Java release (26.2 today). For anything older, the documented route is ViaProxy with Geyser-ViaProxy on it.

Java 21 or newer, and a UDP port. Current Geyser builds are compiled for Java 21. And Bedrock speaks UDP, not TCP, which is the most common reason a manual setup fails on shared hosting — plenty of providers will not open a UDP port at all.

Manual setup, step by step

Paper is the main example, with Fabric and NeoForge differences called out at each step. It is written for a server you control — your own machine, a rented box, anywhere you can edit config files and restart.

Step 1 — Install Geyser

Download the build for your platform from geysermc.org/download.

Restart the server. Geyser writes its config on first start:

• Paper / Spigot — plugins/Geyser-Spigot/config.yml
• Fabric — config/Geyser-Fabric/config.yml
• NeoForge — config/Geyser-NeoForge/config.yml
• Standalone — config.yml beside the jar

Bedrock clients can connect at this point, but only players who own a Java account. Floodgate fixes that next.

Step 2 — Install Floodgate

Floodgate goes on the same server as Geyser, the same way.

• Paper / Spigot — floodgate-spigot.jar from the download page into plugins/
• Fabric / NeoForge — the Floodgate mod from Modrinth into mods/ (Fabric also needs Fabric API)
• Velocity / BungeeCord — the proxy build into the proxy's plugins/

Restart again. Floodgate creates its own folder — plugins/floodgate/ on Paper, config/floodgate/ on a mod loader — containing config.yml and key.pem.

That key.pem is the credential that lets Bedrock accounts bypass Java authentication on your server.

DO NOT DISTRIBUTE THIS KEY TO ANYBODY! — GeyserMC

Do not paste it into a support thread, do not include it in a config dump, do not commit it to a repository. Anyone holding it can join your server as anyone. On a plugin or mod install alongside Geyser you never copy it anywhere — leave it where Floodgate wrote it.

Step 3 — Point Geyser at Floodgate

This is the step people skip, and skipping it makes the whole thing look broken. Open Geyser's config.yml, find the top-level java: section, and set auth-type to floodgate:

java:
  auth-type: floodgate

On a plugin or mod install that is the entire section — Geyser detects the server it is running inside, so there is no address or port to fill in. The three valid values are floodgate (Floodgate is installed here), online (players must own a Java account) and offline (an offline-mode server).

Step 4 — Two settings in server.properties

online-mode=true
enforce-secure-profile=false

Keep online-mode=true. Floodgate exists precisely so you do not have to turn it off: Java players authenticate with Mojang exactly as before, and Bedrock players are vouched for separately through the key. Flipping the server to offline mode instead lets anybody join under any name.

enforce-secure-profile is the one almost every guide forgets. Bedrock accounts have no Mojang chat-signing key, so with secure profiles enforced your Bedrock players connect fine and then cannot chat at all. BungeeCord spells the same setting enforce_secure_profile: false in config.yml; Velocity uses force-key-authentication = false in velocity.toml.

Step 5 — Set the Bedrock port

Still in Geyser's config.yml, the bedrock: section is what your Bedrock friends actually connect to:

bedrock:
  address: 0.0.0.0
  port: 19132
  clone-remote-port: false

19132 is the Bedrock default. Two rules apply: it must allow UDP traffic, and it cannot be shared with any other UDP service — a voice chat plugin or the query listener on the same port will break it.

If your host only opens a single port, set clone-remote-port: true and Geyser listens on the Java server's port number instead, still over UDP. It overrides whatever you put in port, so do not set both and expect the manual value to win.

Restart once here — Steps 3, 4 and 5 all take effect together, and the test in Step 6 checks the port you just set.

Step 6 — Open the port, then test it

On the same machine as the server, Bedrock connects to localhost or 127.0.0.1. Elsewhere on your own network, use the server machine's local IPv4 (192.168.x.x or 10.x.x.x).

If you are hosting and playing on the same Windows PC, Bedrock needs the loopback exemption or it cannot see the server at all. This catches nearly everyone testing their own setup for the first time.

For anyone outside your network, forward UDP 19132 on your router to the machine running the server, and allow it through the OS firewall. If port forwarding is not an option, use a tunnel that carries UDP: playit.gg works, ngrok does not, because it is TCP-only.

Then test from the server console, using the address and Bedrock port your friends will type:

geyser connectiontest <ip> <port>

It reports whether Geyser is reachable from outside, which separates "my config is wrong" from "my router is wrong" in one command.

Step 7 — Join the Java server from Bedrock

On phone, tablet or Windows: Play → Servers → Add Server, give it a name, and enter the address and the Bedrock port (19132 unless you changed it). Java players connect as they always have, on the Java address, with no port.

Two things trip people up here. The address and the port go in separate fields — typing play.example.com:19132 into the address box produces "Invalid IP address!". And Bedrock does not follow SRV records, so an SRV-only domain needs the IPv4 address or a plain A record instead.

Consoles use BedrockConnect or a LAN-proxy app, as described earlier.

Optional: linking Java and Bedrock accounts

If someone plays from both editions, Floodgate's linking feature ties the two accounts to one in-game identity. Global Linking is on by default (player-link.enabled: true, enable-global-linking: true), and despite the name, link.geysermc.org is a Minecraft server rather than a web form: the player joins it from both accounts, runs /linkaccount on one, and enters the returned code on the other.

Warn them first. After linking, the Java account's data is the one that survives, so anything sitting in the Bedrock account's inventory or ender chest should be moved across beforehand.

If Geyser runs separately: Standalone and proxies

Geyser Standalone. Geyser is its own process here, so the java: section needs real values, and key.pem must be copied from the Floodgate config folder into the Geyser Standalone folder. On Geyser-ViaProxy the key goes into /plugins/Geyser/ instead.

java:
  address: 127.0.0.1
  port: 25565
  auth-type: floodgate

Behind BungeeCord or Velocity. Install Floodgate on the proxy — and only the proxy. The wiki is explicit: "You only need to install Floodgate on the BungeeCord or Velocity proxy server, unless you want to use the Floodgate API on the backend servers." Only if you do want that API do you install it on the backends too, give them the same key.pem and config.yml, and set send-floodgate-data: true on the proxy.

Note that Step 4 changes shape here: backend servers behind a proxy run online-mode=false by design, with the proxy handling authentication and forwarding player information. That means ip_forward in BungeeCord's config and bungeecord: true in spigot.yml, or Velocity's modern forwarding with FabricProxy-Lite on a Fabric backend.

Troubleshooting

Almost every failure falls into one of three buckets. GeyserMC's common issues page is the full reference.

Nothing connects

The server does not appear in the Bedrock server list. Add it manually rather than waiting for it to show up. On the same machine use localhost; elsewhere on your network use the server's local IPv4. Consoles will not see it either way and need BedrockConnect.

"Unable to Connect to World". GeyserMC attributes this to Geyser misconfiguration or the network, and its dedicated fix guide works through the real causes in order: connect with the Java IP plus the Bedrock port, avoid Bedrock ports below 10000, forward the port on UDP rather than TCP, add firewall exceptions, and apply the Windows loopback fix. If you do not run a reverse proxy such as TCPShield, also confirm advanced.java.use-haproxy-protocol is false.

"Connection Refused". Geyser cannot reach the Java server. Check the address spelling, that the Java server is running, and that the port is right. If an anti-DDoS layer sits in front, whitelist Geyser.

java.net.BindException: Address already in use. Something already holds that port — most often a second Geyser instance. Close it, or pick a different port.

Stuck on "Locating Server" with no error. Either an outdated Java runtime (update to Java 21) or a network-level MTU problem. Lower advanced.bedrock.mtu in steps of 100 and retry.

Your host will not open a UDP port. Then Bedrock cannot reach you. GeyserMC notes a workaround that works with some providers — request a Nukkit server during setup so a UDP port gets allocated, then swap in your real server software — but it applies only to Geyser Standalone, and it does not survive hosts that auto-update the jar.

Version mismatches

Login and Floodgate errors

"Cannot reply to EncryptionRequestPacket without profile and access token". The classic Floodgate misconfiguration. Either a key.pem was copied into Geyser's folder on a setup that never needed it — only Standalone and proxy installs require that copy — or Geyser's auth-type and the server's mode disagree. Remove the stray key and make the two consistent.

"Missing profile key. This server requires secure profiles." Secure chat is enforced and Bedrock accounts cannot satisfy it. Set enforce-secure-profile=false as in Step 4.

Bedrock clients freeze the first time they open the command menu. Command suggestion processing. Set command-suggestions: false under the gameplay: section of Geyser's config, or trim the command list with a plugin.

Keeping it working after Minecraft updates

This is where hand-assembled setups usually die. Geyser can only translate a release it has been taught, and that teaching can land well after Minecraft ships an update — while a server that auto-updates breaks crossplay for everyone the morning after.

What you do about it depends on the platform, and the two answers are genuinely different:

• Paper and Spigot — pin the server a release behind until Geyser catches up, and run ViaVersion so freshly updated Java launchers still get in. This works because Geyser-Spigot supports a range of server versions from 1.20.5 up.
• Fabric and NeoForge — pinning does not work, because those builds only run on the newest release. The documented answer is ViaProxy with Geyser-ViaProxy in front. Floodgate still works there, with one wrinkle: ViaProxy manages authentication itself, so the auth-type you set in Step 3 is ignored.

Plenty of groups run Geyser on no-cost hosts and it works fine; the difference is who does the version-matching every time Minecraft ships. Geyser upkeep on Aternos compared with Pixly covers that trade-off.

If you would rather not own the maintenance

What this costs is not the afternoon. It is every Minecraft update afterwards.

On Pixly, Bedrock cross-play is a switch in Settings. Flip it, restart once, and the server installs Geyser and Floodgate itself, matched to your version, with ViaVersion added so updated Java clients keep connecting. The Connection card then shows both addresses side by side — Java for Java, address plus port for Bedrock. It is included on every plan, and there is no per-player charge, so adding Bedrock friends changes nothing on the bill.

About 10 hours of play come with a new account, which is enough for a mixed group to find out whether crossplay actually works for them before deciding anything.