Your friend on Xbox has been staring at the server browser for ten minutes. You've sent them the IP. You've sent them the port. You've sent them a screenshot of the IP and the port, with an arrow. And they still cannot see your world, because on a crossplay Valheim server the IP and port are not how they get in, and nothing in the game tells either of you that.
That's the whole problem in one paragraph. It's about to get a lot more common, because on September 9 Valheim 1.0 brings PlayStation 5 and Nintendo Switch 2 into a game that already ran on PC, Mac, Linux, Xbox One and Xbox Series X|S, with full crossplay between all of them. A lot of people are about to try mixing platforms on a dedicated server for the first time.
We've hosted Valheim since the game launched, and mixed-platform connection problems are far and away the ticket we get most. So here's the whole picture. What crossplay actually does, where the join code comes from, how a console player gets in, and the handful of things that reliably go wrong. If you haven't got a server up yet, our Valheim hosting page is the quickest way to have one running before the ninth.
Which platforms actually play together
All of them. That's the short version, and it's worth stating plainly because the older articles floating around still describe Valheim crossplay as a Steam and Xbox arrangement, which is what it was for the first couple of years.
Iron Gate's own wording, from the release date announcement in June: the release hits "PC, Linux, Mac, Xbox One and Xbox Series X|S as per usual, and now we're also adding PlayStation 5 and Nintendo Switch 2 to the roster", with "full crossplay between all the platforms".
I've seen people assume there must be a catch buried in there somewhere. There isn't. There's no tiering and no pairs that are excluded. A Switch 2 player and a Linux player can share a world. What matters is not which platforms, but whether crossplay is switched on at both ends. The server has to be started in crossplay mode, which is a decision you make before anyone connects, and the joining player needs crossplay enabled on their side too. Iron Gate are explicit about that second half, and it's the half people forget.
What the crossplay flag actually does
This is where most of the confusion starts, so it's worth being precise.
Valheim's dedicated server takes a -crossplay argument. Enabling crossplay means starting the server with that argument. That's it. There is no config file entry, no in-game menu, and no runtime toggle.
What the argument does is swap the online backend. Iron Gate describe it as running "the Server on the Crossplay backend (PlayFab), which lets users from any platform join", and note that without the argument "the Steam backend is used". That's the whole of it. PlayFab is Microsoft's cross-platform service, and it's the layer every non-Steam client can actually reach. In the game's own code the flag sets exactly one thing, the online backend type, and nothing else in the startup path branches on it.
That matters for two reasons.
The first is that crossplay is not a feature you switch on to make your server better. It's a different network path with different tradeoffs. Steam players on a crossplay server connect through PlayFab too, not through Steam, so you have changed things for everybody, not just the console arrivals.
The second is the myth. You will read, in a lot of places including hosting blogs that ought to know better, that crossplay and BepInEx mods cannot run at the same time, usually with an explanation about the crossplay backend hooking the same DLLs the mod loader uses. That explanation is wrong, and so is the conclusion. We'll come back to it further down, because it deserves its own section.
The join code, and where to find it
When a server starts in crossplay mode it registers a session with PlayFab, and PlayFab hands back a six-digit join code. Numeric, six characters, nothing else. 604510 is the shape of it.
That code is the only thing your console and Game Pass players need. Not the IP. Not the port. Just the six digits and, if you've set one, the password.
There are two places to get it, and most guides only mention the harder one.
The easy route is in game. Join your own server, open the pause menu, and the join code is sitting right there. Iron Gate's own instruction is to click it to copy. That's the one to hand most people.
The other route is the server log. That's where you go when nobody can get in yet, or when you want the code before anyone has joined at all. Here's the sequence a real crossplay server writes on startup, in order:
Opened PlayFab server
Logged in PlayFab user via custom ID
New session server "Your Server Name" that has join code , now 0 player(s)
Created PlayFab lobby with ID "0cff13b8-a70a-4313-9b7a-6b5b9ed5a246.r-20230509"
Session "Your Server Name" registered with join code 604510
Session "Your Server Name" with join code 604510 and IP 203.0.113.4:2456 is active with 0 player(s)
Look closely at the third line. The session gets announced before the code exists, so that line reads has join code , with an empty space where the number should be. Three seconds later the lobby is created and the code is registered.
I want to flag this one hard, because it's the single most common way people conclude crossplay is broken when it isn't. They start the server, tail the log, see a join code line with nothing in it, and go looking for a fix. There's nothing to fix. Wait a moment and read further down.
Once the server is up, the code shows in every session status line and every join and leave event, so you don't need to catch it at startup. Search the log for "join code" and take the most recent line that has a number in it.
The code is tied to the session, not to your server. It's issued when the lobby is created, and a restart creates a new lobby. Treat it as something that can change whenever the server restarts, which means don't paint it on your Discord banner. Put it somewhere you can edit quickly, and check it after any restart or update. If your group is small, the easiest habit is to post it in chat when you bring the server up.
Getting a console player in
From the player's side it's short, which is the point.
- They open Valheim and pick a character, the same as always.
- They go to Join Game and press Add server.
- They paste the six digits into the box that would otherwise take an address.
- If the server has a password, they enter it next.
That's the entire flow. If your server is public, it can also turn up in the community list, but the code is the reliable route and it's the one to send people.
Two things that trip this up. The first is that the code has to be current, per the point above. The second is the password, which has rules of its own that catch people out and are worth a paragraph.
Valheim will refuse to start a public server whose password appears inside the world name or the seed. Not the server name, which is what a lot of guides say. The world name and the seed. If your world is called Midgard and you set the password to mid, the server writes an error and exits rather than starting with a weak password. It doesn't fail quietly, which is at least something: you'll find a line beginning Error bad password: right before it stops.
Admin and ban lists change shape
This is the part that catches server owners rather than players, and it's easy to miss because everything looks like it should work.
On a Steam-only server the admin list is a file of bare SteamID64 numbers, and plenty of guides still describe it that way. Once crossplay is involved those guides are out of date.
Iron Gate's own instruction is to add one Platform User ID per line, in the format [Platform]_[User ID], and they flag that it's case sensitive. So it's the platform name, an underscore, then the account ID.
A Steam player connecting through the crossplay backend shows up in the log like this:
PlayFab socket with remote ID playfab/EFEFD7F454DC3473 received local Platform ID Steam_76561198373857942
That's the same SteamID64 you already know with Steam_ on the front. An Xbox or Game Pass player arrives the same way, as Xbox_ followed by a sixteen-digit number, so Xbox_2535416401464117 is the shape you're looking for. Because the format is case sensitive, copy it exactly as printed rather than retyping it.
There are two ways to get an ID, and the log is the slower one. In game, press F2: the panel lists each connected player's ID next to their name. That's the route when someone is already online, and it's much less fiddly than trawling a log.
One warning while you're in these files, because it's the most expensive mistake available here. permittedlist.txt is a whitelist, not a permissions list, and Iron Gate put it bluntly: adding one person to the permitted list bans everyone else from the server. If all you wanted was to make someone an admin, the file you want is adminlist.txt and nothing else.
So: don't guess at IDs and don't retype them. Have the player join once, take the ID from F2 or the log in its exact prefixed form, and paste it.
Mods: the honest version
Here's the correction, and I'll own it, because we had this wrong in our own articles until recently and so does most of the internet.
Crossplay does not stop BepInEx from loading. The two run together. I can point at a real dedicated server log where BepInEx starts, reports the plugins it's loading, finishes its chainloader, and then the same server opens its PlayFab session and registers a join code. All in one run, seconds apart.
The reason is structural. BepInEx attaches through a loader that runs when the game's runtime initialises, which happens before the game has looked at its own command line arguments. A flag parsed later cannot retroactively prevent a loader that has already run. The mechanism people cite for the two being incompatible describes something that isn't possible in that order.
So why does "turn crossplay off to fix your mods" work often enough that everyone repeats it?
Because it's a real workaround for a different problem. Individual mods break under crossplay. A mod that reads SteamID64s for its own permissions, or leans on Steam networking directly, has had the ground moved under it when the backend changed. There was a well-known case of exactly this: a popular modding framework threw an error that only appeared on crossplay servers, people found that disabling crossplay avoided it, and the author shipped a fix within a day. The workaround was sound. The explanation that grew around it was not.
Which leaves the limit that actually matters, and it has nothing to do with the loader:
Console players cannot install mods. There's no route for it on PS5, Switch 2 or Xbox. So any mod that needs to be present on the client locks those players out, regardless of what your server is running. Server-side mods, the ones that change the world rather than the client, are fine.
That gives you a real decision rather than a fake one:
- Console friends in the world? Run vanilla, or restrict yourself to server-side-only mods.
- All on PC and heavily modded? Leave crossplay off. You lose nothing, and you avoid the class of mod bugs that only appear on the PlayFab backend.
Make the call before you invite people. Switching afterwards means either dropping your console players or stripping your modlist, and both of those conversations are worse than the one you'd have had up front. If you go the modded route, our mod installation guide walks through it.
What usually goes wrong
The failure modes cluster, and they're nearly all one of these five. If none of them match what you're seeing, the causes that have nothing to do with crossplay are in our connection troubleshooting guide.
The code is blank in the log. You read too early. The session line prints before PlayFab returns the code. Read further down.
The code stopped working. The server restarted and got a new lobby, and therefore a new code. Pull the current one from the log.
A console player can't find the server, but PC players can. The server isn't running in crossplay mode. Steam players connect fine over the default backend, so the server looks healthy from where you're standing. Check that it started with the crossplay argument.
The server won't start at all after a password change. Check whether the password is a substring of your world name or seed on a public server. Look for Error bad password: near the end of the log.
An Xbox player has no crossplay option at all. Nothing to do with your server. Iron Gate point at the console's parental control settings, which can hide the toggle outright. Get them to check there before you start pulling your own config apart.
Mods stopped behaving once console players joined. Not the loader. It's a specific mod assuming Steam. Work out which one by elimination, and check whether the author has shipped a crossplay-aware build.
Before launch day
If you're planning to mix platforms when 1.0 lands, three things are worth doing in advance rather than on the night.
Decide the crossplay question and the mods question together, because they're the same question. Get your server into the mode you actually want now, while nobody's waiting on you.
Find your join code once and confirm it works, ideally with someone on a different platform. Testing the path before twelve people are trying to use it is worth an hour of your time, and I promise it's an hour you'd rather spend now than on launch night.
And gather your players' platform-prefixed IDs as they join, rather than trying to reconstruct an admin list under pressure later.
If you're also bringing an existing world onto the server before launch, that's a separate job with its own traps, and it's written up in How to Move a Valheim World to a Dedicated Server. If you're setting a world up from scratch first, the getting started guide covers the basics.
If you get stuck on any of it, open a ticket and we'll read the log with you. Reading a Valheim startup log is a skill, and the join code line being empty on first glance has caught out more people than any actual fault ever has.