The address players are sent to, exactly as it would appear in the Multiplayer server list. IPv6 addresses are quoted automatically because unquoted command strings cannot contain colons.
Left on default, the port argument is omitted and the game connects to 25565.
With the players argument left out, /transfer sends the player who executes it. Run from the server console this form fails, because the console is not a player; pick Specific players instead.
Run from the server console or as an operator (permission level 3). The destination server must have accepts-transfers=true in server.properties; without a port argument the game connects to port 25565.
Quick rule: the transfer only succeeds when the destination server has accepts-transfers=true in its server.properties; otherwise players are disconnected with the message that transfers are disabled. The command itself exists only on dedicated multiplayer servers, not in singleplayer or LAN worlds, and the player is fully disconnected and reconnected to the new address, just as if they had joined it from the server list.
/transfer moves a player from the server they are on to a different server, by hostname and port. Added in Java Edition 1.20.5, it works without any proxy software, but only when the destination server has accepts-transfers=true in its server.properties.
When the command runs, the server sends the targeted players a transfer packet containing the new address. Each client disconnects and immediately reconnects to the destination, exactly as if the player had clicked the server in their Multiplayer list. There is no shared session or hidden tunnel: the destination is a completely separate server, with its own world, whitelist and player data.
The command requires permission level 3, so it can be run by operators or from the server console, and it exists only on dedicated servers: singleplayer worlds and LAN sessions do not register it. Typical uses are vanilla server networks (a hub world that sends players to minigame or creative servers), moving everyone to a new address during a migration, and command-block-free lobby systems on small setups that do not want to run BungeeCord or Velocity.
The generator above builds the exact command: enter the hostname, choose the default or a custom port, and either transfer whoever runs the command or pick specific players with the selector builder.
The full form of the command is /transfer <hostname> [<port>] [<players>]. The arguments are positional and fill in from the left: hostname alone is valid, hostname plus port is valid, but listing players always requires the port to be written out first.
The players argument only accepts players. Selectors such as @a, @p, @r and @s work directly, exact player names can be listed, and @e matches only when restricted with type=player. The command was added in Java Edition 1.20.5 and its syntax has not changed since.
Five ready-to-paste commands covering the common cases. Run them as an operator or from the console of the server the players are currently on:
/transfer play.example.com
Sends the player who runs the command to play.example.com on the default port 25565. The shortest valid form.
/transfer play.example.com 25566
Same self-transfer, but to a server listening on port 25566 instead of the default.
/transfer hub.example.net 25565 @a
Moves every player online to the hub server at once. The port has to be written out because players can only follow a port.
/transfer minigames.example.org 25565 Steve Alex
Transfers exactly two named players and leaves everyone else where they are.
/transfer "2001:db8::1" 25565 @s
An IPv6 destination has to be quoted: unquoted command strings cannot contain colons. @s transfers the executing player, same as omitting the argument.
Transfers are refused by default. The server players are sent to must opt in; the server running the command needs no configuration at all:
1. Stop the destination server, or plan to restart it: server.properties is only read at startup.
2. Open server.properties in the server folder and set accepts-transfers=true. Add the line if it is missing.
3. Start the server again. Transferred clients can now join; everything else about the server, including normal direct connections, is unchanged.
If the setting is still false, transferred players are disconnected with Transfers are disabled on this server and stay on neither server, so flip the setting before wiring up any hub commands.
One thing to be aware of: accepts-transfers=true accepts transfer connections from anywhere, not just from your own servers. Java Edition 1.20.5 also added a cookie system that lets servers store a small amount of signed data on the client across transfers; server software and plugins use it to verify that a player really came from a trusted server. Vanilla setups that just move players between their own machines usually do not need to do anything beyond enabling the setting.
/transfer sends a player from the server they are currently on to a different server, identified by hostname and port. The player's client is disconnected and reconnects to the new address automatically, exactly as if they had joined it from the Multiplayer screen. It is the vanilla way to move players between servers without a BungeeCord or Velocity proxy.
Java Edition 1.20.5, together with the accepts-transfers server property and the transfer packet the command uses. The syntax has not changed since: /transfer <hostname> [<port>] [<players>]. Older servers do not have the command at all, which is why the generator's version picker starts at 1.20.5.
The destination server is refusing transferred connections. Transfers are off by default: open server.properties on the destination server, set accepts-transfers=true and restart it. Only the receiving server needs the setting; the server running /transfer needs nothing special.
No. The command is only registered on dedicated multiplayer servers, like /ban or /whitelist. Singleplayer worlds and Open to LAN sessions do not have it, and Realms does not expose it or the accepts-transfers setting. You also need permission level 3 (operator) to run it.
Use the players argument with @a, for example /transfer play.example.com 25565 @a. Note that the port must be written out whenever you list players, because the arguments are positional: players can only come after a port. Any player selector works as long as it resolves to players, and named players can be listed too.
For small setups, often yes: two or three vanilla servers can move players between each other with no proxy software at all. A proxy still has advantages for larger networks: one public address for everything, shared player counts and plugin messaging. /transfer is a plain reconnect, so anything you want to carry across servers has to be handled with the cookie system added alongside it or by your own plugins.
Sharing a singleplayer world over LAN instead? Or browse more Minecraft tools:
