Minecraft Bedrock vs Java hosting: which one to run

Java and Bedrock are not two versions of one game as far as the server is concerned. They are separate programs, written in different languages, speaking different protocols on different ports, storing worlds in different formats, extended by different things. Picking the wrong one is a migration, not a setting. The short answer: if your players are on consoles, phones or the Microsoft Store version, you need Bedrock or a bridge. If they are on desktops and you want plugins, land claims, permissions and the whole tooling ecosystem, you want Java. If you have both kinds of player, the practical answer for most groups is a Java server running Paper with Geyser and Floodgate in front of it - and this post is honest about what that does and does not give you.

Two programs, not two editions#

The differences are structural rather than cosmetic. This table is the whole argument compressed.

Two rows on that table do more damage than the rest. No ARM and no macOS for Bedrock means the server binary is fussier about where it lives than a Java jar is. And clients auto-update: a Bedrock player's phone or console updates itself, and when the protocol changes they cannot join until the server is updated too. A Java server can sit on 1.20.1 for a year and players simply install that version from the launcher. A Bedrock server is on a release treadmill it does not control.

Who is playing decides it#

Everything else is secondary to this. Ask the group what they own.

• Consoles - Xbox, PlayStation, Switch. Bedrock, and only Bedrock. There is no Java client for a console and there never will be. Note also that console clients cannot type an arbitrary server address into the UI; joining a third-party server means a DNS redirect helper on the same network or one of the phone apps that provides one. Windows, mobile and Fire clients have a plain Add Server button with an address and port field.
• Phones and tablets. Bedrock.
• Desktop players who bought the game from Minecraft.com. Both, since a purchase includes Java and Bedrock on Windows. Which one they usually launch is the question worth asking.
• Anyone who mods, or wants plugins. Java. This is not close.

The honest framing is that Bedrock is the edition for people who did not choose an edition, and Java is the edition for people who did. A family server for two adults and three children on tablets is a Bedrock server. A survival community with land claims, an economy and a Discord bridge is a Java server. A group that is half and half is the interesting case, and Geyser is its answer.

Ports, addresses and getting people in#

Bedrock uses UDP. Java uses TCP. This single fact causes more "the server is running but nobody can join" tickets than everything else combined, because a firewall rule written for one does nothing for the other. Game server ports explained covers the general case and TCP vs UDP for game servers covers why games split this way.

The address is the other half. Java clients do an SRV lookup, which is how a server on a non-standard port can be joined by typing a bare domain with no port - see SRV records for Minecraft for the record format. Bedrock clients do not follow SRV records. A Bedrock player must be given a host and a port as two separate fields, so a tidy play.example.com still needs 19132 typed next to it unless the server genuinely listens on the default. Plan for that when you pick a port, and see connecting a domain to a game server for the A record itself.

On a panel-based host each plan states how many port allocations it has, and the Minecraft plans here come with one. You add more on the Network tab, which is exactly what you do when you want a Bedrock listener alongside the Java one, or a web map, or query and RCON on separate numbers.

Configuration: the two server.properties files#

Both servers keep their settings in a file called server.properties, and the two files have almost nothing in common. Copying keys from a Java guide into a Bedrock config is a popular way to waste an afternoon.

server-port=25565max-players=20view-distance=8simulation-distance=6online-mode=truewhite-list=falseenable-rcon=falsespawn-protection=16

server-port=19132server-portv6=19133max-players=10view-distance=32tick-distance=4online-mode=trueallow-list=falsedefault-player-permission-level=membermax-threads=8

Some Bedrock-specific notes that are not obvious from the key names:

• `view-distance` defaults to `32`, which is enormous and the first thing to lower on a busy server. tick-distance is the simulation radius and defaults to 4, with a range of 4 to 12 - it is the equivalent of Java's simulation-distance and is already conservative.
• `allow-list` is the newer name for what used to be white-list, and the file is allowlist.json rather than whitelist.json. Older guides use the old names.
• `default-player-permission-level` takes visitor, member or operator. Operators are set in permissions.json, keyed by Xbox Live XUID rather than by name.
• `max-threads` caps the worker threads; 0 means use what the machine has.

Java's ops.json, whitelist.json, banned-players.json and banned-ips.json have direct Bedrock equivalents in permissions.json and allowlist.json, but the identifiers differ: Java uses account UUIDs, Bedrock uses XUIDs. Every `server.properties` key explained covers the Java file in full.

Plugins, add-ons and what each side gives up#

This is where the two ecosystems stop being comparable.

Java has Bukkit-derived plugins, which is fifteen years of accumulated tooling: permissions, land claims, block logging with rollback, economies, web maps, anti-cheat, profilers, Discord bridges. They run server-side only, so players join with an unmodified client. Separately it has mods, which change the game itself and require every player to install the pack. And it has datapacks, which work on both plugin servers and vanilla. Paper, Fabric or vanilla covers that split, and the plugins worth installing covers the short list that earns its keep.

Bedrock has add-ons: behaviour packs and resource packs, dropped into behavior_packs/ and resource_packs/ and enabled per world through world_behavior_packs.json. They can retexture, rebalance, add entities and items, and - through the scripting API, which is JavaScript running inside a behaviour pack - do a surprising amount of real logic. What they cannot do is most of what a server admin wants. There is no official land-claim system, no rollback of griefing, no permissions beyond three levels, no economy framework.

Unofficial server software exists for Bedrock - PocketMine-MP and Nukkit are the long-running ones - and they do provide plugin APIs. The catch is that both reimplement the protocol from scratch, which means they trail the official releases after every update and do not implement every vanilla feature. That is a reasonable trade for a minigame network and a poor one for a survival world.

So the honest summary: Bedrock gives you a server that anyone can join from anything and very little control over what happens on it. Java gives you total control and excludes every console player.

Sizing, performance and what each costs to run#

Bedrock is written in C++ and Java is not, and it shows in the memory numbers. There is no heap to tune, no garbage collector to configure, no -Xmx to get wrong. A Bedrock server for a handful of players is happy in 1 to 2 GB; the same group on Java wants 2 to 4 GB once the JVM's own overhead is counted.

Do not read that table as "Bedrock is cheaper, run Bedrock". The memory difference is one tier, and the tooling difference is everything. Where Bedrock does genuinely win is the very small end: a family server on a tablet-sized player count runs on almost nothing.

Both are bounded by a single simulation thread and by how much world is loaded at once, so the tuning instincts transfer even though the key names do not. Lower the view distance before you buy memory; that is true on both sides. How much RAM a Minecraft server needs has the Java arithmetic in full, and most of the reasoning applies to Bedrock with the heap section removed.

Geyser and Floodgate: the bridge and its gaps#

Geyser translates the Bedrock protocol into the Java protocol, so Bedrock clients can join a Java server. Floodgate sits beside it and lets those players in without owning a Java account. Together they are the reason most mixed groups end up on Java.

Geyser runs as a plugin on Paper, as a plugin on a Velocity or BungeeCord proxy, as a mod on Fabric or NeoForge, or standalone on its own machine. The plugin route is the simplest: drop the jar in plugins/, start once to generate config.yml, set bedrock.port and the authentication mode, restart. Floodgate needs a key.pem shared with Geyser, and by default it prefixes Bedrock usernames with a dot so they cannot collide with Java names. The practical requirement on a host is the extra allocation: Geyser needs UDP 19132 in addition to the Java server's TCP port, added on the Network tab.

What it does not do, and you should test each of these before promising anything:

• Mods do not translate. Geyser speaks the vanilla Java protocol. A Forge or Fabric server with custom content is not reachable this way.
• Custom item models and some plugin interfaces are rough. Inventory-menu plugins, custom heads and resource-pack-driven item art are the usual sources of "it looks wrong on my phone".
• Movement differs. Bedrock's movement and block-placement rules are not identical to Java's, and movement-based anti-cheat plugins produce false positives on Bedrock players until they are configured for it.
• Resource packs are a separate pipeline. A Java resource pack is not a Bedrock one, so visual parity means maintaining two.

None of that makes it a bad idea. For a group of friends where three people are on Xbox, it is clearly the right answer. For a public server promising a polished experience to Bedrock players, budget real testing time. Geyser and Floodgate in detail walks through the config.

Worlds do not move between them#

Anvil and LevelDB are different on disk and different in what they can express. You cannot copy a world folder from one to the other, and the converters that exist are lossy.

The tools people use are Chunker, a browser-based converter, and Amulet, a desktop world editor. Both will get terrain and most blocks across. What tends not to survive:

1. Command blocks and functions. The command syntax overlaps but is not the same, and anything clever will need rewriting.
2. Plugin and mod data. Claims, shops, logged blocks and custom items live in databases and NBT that the other edition has no concept of.
3. Blocks with no counterpart. The two editions have diverged on a handful of blocks and block states, and the converter picks something reasonable.
4. Entity and inventory NBT edge cases. Named items, custom potions and anything a plugin wrote by hand.

Treat a conversion as a one-way migration with manual repair afterwards, not a sync. Convert a copy, walk the important builds, and keep the original world forever. Backups that actually restore is the habit that makes this survivable, and it is worth taking a locked backup before you start rather than a copy sitting in the same folder.

The other reason to decide early: the version treadmill. A Java server is upgraded when you choose, with a procedure and a rollback. A Bedrock server is upgraded when Mojang ships, because the clients already did.

FAQ#

Can Bedrock and Java players join the same server?

Not natively - they are different protocols. The working route is a Java server running Geyser and Floodgate, which translates Bedrock connections. It needs a second, UDP port and some tolerance for visual quirks, and it rules out mods, but for a mixed group of friends it works well.

Is a Bedrock server cheaper to run than a Java one?

Slightly. There is no JVM heap, so a small Bedrock server fits in 1 to 2 GB where Java wants 2 to 4. The difference is usually one tier, which is less than it sounds next to the difference in what you can do with the server.

Why can my Xbox not see the server?

Console clients have no field for an arbitrary server address. Players either use a DNS redirect helper on the same network, a companion phone app that provides one, or a Realm. Windows, mobile and Fire clients have a normal Add Server option with a host and port.

Do I need to open TCP or UDP?

Java is TCP on 25565. Bedrock is UDP on 19132, and its IPv6 listener is UDP on 19133. A rule written for the wrong protocol is the most common reason a server starts fine and nobody can reach it.

Can I convert my Bedrock world to Java?

With a converter such as Chunker or Amulet, mostly. Terrain and ordinary blocks survive. Command blocks, custom entity data and anything a plugin or add-on wrote do not. Convert a copy, inspect it properly, and keep the original.

Does Bedrock support plugins?

Not officially. Add-ons - behaviour packs, resource packs and the scripting API - are the supported way to change the game, and they cover content far better than they cover administration. Third-party server software such as PocketMine-MP and Nukkit does offer plugins, at the cost of trailing official releases.