The world is incomplete
Valheim needs both .fwl and .db. Palworld needs Level.sav plus Players. Miss one half and the server can look healthy while loading an empty world or fresh characters.
Free tool
Check your world before you move it to a dedicated server. Point it at your Valheim or Palworld save and it tells you whether the files a server actually needs are there, and what to fix before you upload them.
Your files stay in your browser. They are never uploaded, and no account is needed. The only thing we receive is an anonymous counter: which game you checked, the result category, and the issue codes. No file names, world names, seeds or contents.
Drop your world files here
Both files of one world: <world>.fwl and <world>.db, with no _backup_auto- timestamp in the name. On Windows they live in %USERPROFILE%\AppData\LocalLow\IronGate\Valheim\worlds_local. If Steam Cloud is on, the live copy can instead sit in your Steam userdata/<id>/892970/remote/worlds folder, which is also where it lives on macOS.
Three checks before upload
Almost none of the failed migrations we see are corrupted saves. They are complete worlds uploaded with a piece missing, or a world that quietly brought settings from the machine it used to live on. Both are visible before anything is uploaded.
Valheim needs both .fwl and .db. Palworld needs Level.sav plus Players. Miss one half and the server can look healthy while loading an empty world or fresh characters.
Palworld's WorldOption.sav can override the destination's identity and port. The server runs, but it can disappear from the community browser.
A newer build can change its save format. The checker reports that as unrecognized, never corrupt, because only the game itself can prove the difference.
Private by design
The checker reads small slices locally and forgets them when you close the tab. It never uploads the .db or Level.sav, so a 400 MB world is as quick to check as a new one.
Ready for a destination?
GHosting gives the world file access, a live console and simple settings, so the move is an upload and a restart rather than a Linux project. Plans are fixed-term, and nothing renews automatically.
No. The check runs in your browser: the files are read in small slices on your own machine and the report is built there. What we do receive is the same anonymous counter every page on this site sends, plus which game you checked, the result category and the issue codes, so we can tell whether the tool is useful. It never carries a file name, world name, seed, player id or any file content, and you can confirm all of that in your browser network tab.
It means you have the files a migration needs and none of the known traps apply, so the move is worth attempting. It is not a promise the world is undamaged or that the destination server will load it. Keep your source copy until the server has run once and you have joined.
The .fwl holds the world name, seed and format version. The .db holds everything that exists in the world. Upload only one and the server generates a fresh world around it, which looks exactly like losing your save.
A world hosted from the Palworld client carries WorldOption.sav, and Palworld reads that in preference to PalWorldSettings.ini. It is a complete settings store, so it also brings the old server name and advertised port, which is why a healthy server can be missing from the community browser while direct connections work.
The world does. The co-op host character does not, because a client-hosted world stores the host under a fixed identity while a dedicated server keys every player to their own account. Everyone else keeps their character. The host needs a separate migration.
Valheim and Palworld. Those are the two where a migration fails for reasons you can see in the files before uploading. More games follow once this one earns its keep.