How crossplay works
The server-side bridge architecture — Bedrock packet translation and Java-account-free authentication.
You don't need to know any of this to play. But if you're curious about why a Bedrock player on a phone can fight a Java player on a desktop in the same world, here's the architecture.
The bridge
A server-side translation layer accepts native Bedrock connections on UDP port 19132 and translates them into the Java protocol the server speaks internally. From the server's perspective, every connection is "a Java player." From the Bedrock client's perspective, it's connecting to a normal Bedrock server. Neither end knows the other is using a different edition.
This bridge handles:
- Packet translation — Bedrock packets in, Java packets out, and back
- Inventory translation — Bedrock's slot-grid vs Java's container-windows
- Block ID mapping — most blocks have a 1:1 Bedrock↔Java match; the few that don't get the closest equivalent
- Item translation — same idea for items, tools, armor, enchantments
- Skin support — Bedrock skins display correctly to Java players
The auth bypass
A second component handles authentication without a Java account. When a Bedrock player connects:
- Their Bedrock client provides standard Bedrock auth (Microsoft account or device-linked)
- The bridge generates a deterministic linked Java identity from that Bedrock identity
- The server treats the Bedrock player as a normal Java player with that linked identity
- Their username appears in chat (with a small visual marker indicating Bedrock origin)
This is why the server is online-mode for Java but accepts Bedrock without a Java license. Bedrock players are authenticated by Microsoft on their own track; the bridge trusts that.
A custom Sunday Market bridge layer sits on top
In addition to the standard Bedrock bridge, Sunday Market runs a custom plugin with exactly one job: getting biome colors right for Bedrock players.
Sunday Market's world is built on a deep stack of custom biomes — terrain that doesn't exist in vanilla Minecraft. Those custom biomes have no matching Bedrock ID, so a Bedrock client connecting through the bridge would render their grass, water, and fog with the wrong colors. The custom layer auto-detects every one of those biomes and maps it to the nearest vanilla equivalent, so Bedrock sees a sensible, good-looking fallback instead of a broken palette.
It's invisible and automatic — no player ever touches it. It just means the world looks the way it should whether you're on Java or Bedrock.
What Bedrock players experience differently
Mostly nothing. The differences that exist:
- Inventory and chest UIs use Bedrock's native rendering (this is normal)
- Touch controls work; controller works; mouse-keyboard works (Win10/11 Bedrock)
- Some chat formatting (gradients, hover cards) renders simpler on Bedrock — the content is preserved, the richness is reduced
Performance
Bedrock players generally see better performance per device because Bedrock's renderer is more optimized for low-end hardware. A phone or Switch can connect and play comfortably; a Java client of the same era would struggle.
The trade-off: some Java-side features are reduced or absent on Bedrock (richer chat formatting, certain mod-style UI menus that were built for Java's GUI system). The bridge does its best to preserve everything important.
See also
- Bedrock tips — controller, touch, hot-bar tips
- Version compat — what client versions can connect
- Connecting from Bedrock — step-by-step setup