World file formats

World file formats

Valheim 1.0 changed how a world is stored on disk. This page is the detail behind Worlds, backups and restore: what changed, what conversion does to your files, and how BakaLoader decides what is a world and what is a backup of one.

You do not need any of this to run a server. Read it if a world went missing from a list, if you want to know whether you can still open a world on an older build, or if you are about to move files by hand.

The two shapes

A pre-1.0 world is two files sitting in the worlds folder. Midgard.fwl holds the seed and the world settings. Midgard.db holds everything that has been built, killed, dropped or explored.

A 1.0 world is a folder named after the world. Inside it are _main.{N}.fwl2, _main.{N}.db2, _main.{N}.chunks and _main.{N}.ok, plus the chunk files themselves. N is a generation number that goes up by one every time the game saves.

The .ok file is the important one. The game writes it last, once the rest of the generation is safely on disk. So the live save is the highest N that has all four files. A generation with no .ok is a save that was still being written, or one that was interrupted.

BakaLoader uses the same rule everywhere. That is why the Barrow greys out a backup with "This snapshot holds no finished save, so there is nothing to restore from it yet." It is not being cautious for the sake of it. There genuinely is no finished world in that folder.

What conversion does

When a 1.0 server loads a world in the old format, the world still works. Nothing changes yet. The next time the server saves, the game rewrites the world as a 1.0 folder and renames the old .fwl and .db aside as Midgard_backup_{stamp}.fwl and Midgard_backup_{stamp}.db.

BakaLoader watches the server's own output for the line ZNet.LoadOldWorld done and, when it sees it, says so in the log:

Midgard is in the old format. The next save converts it to the 1.0 format and keeps the old files as a backup. Older servers will not be able to load it afterwards.

That last sentence is the whole point. Conversion goes one way. A 0.220 server cannot open a converted world. If there is any chance you will want to run this world on an older build, take a copy of the files before that first save, not after.

The renamed pair is a real backup layer. It shows in the Barrow as PRE-1.0 ORIGINAL, and you can restore it. Restoring it deletes the 1.0 folder and puts the old pair back, so the world is pre-1.0 again until the next save converts it once more.

What BakaLoader shows as a world

If a folder and a legacy pair both exist with the same name, the folder wins and the pair is hidden. It has to be that way: the pair is what the folder was made from, and listing both would look like two worlds when there is one.

Deleting a converted world removes the hidden pair too. If it did not, the pair would stop being shadowed and would come back as its own world the next time the folder was scanned. The sweep now covers both worlds subfolders, worlds_local and worlds, so a same named world sitting next door cannot come back either.

What counts as a backup

This one caused a real bug, so it is worth being exact. BakaLoader uses Valheim's own two part test, taken from the game's SaveSystem.GetSaveInfo:

The name must contain a timestamp the game's own pattern can read. Six number groups, hyphens between them optional, matched anywhere in the name. So 20260909180000, 20260909-180000 and 2026-09-09-18-00-00 all count.

And the literal text _backup_ must sit at the second to last underscore in the name.

Both, or it is not a backup, it is a world.

There is a third shape, and 1.0.1 changed which side of the line it falls on. A pair named {world}_{stamp} with a stamp but no _backup_ marker is what the game calls a rolling save. The game files it under the name trimmed at the last underscore and never opens it as a world of its own.

So BakaLoader treats it the same way. Grimhold_20260909180000 is a layer of Grimhold, not a world. It is out of the world picker, out of the adoptable worlds list and out of the new server flow, and it is back in the Barrow under the trimmed name. Before 1.0.1 it was offered as a world you could adopt, which produced a realm the game would never load.

The other direction matters too. A world whose own name happens to end in _backup, or contains _backup_ somewhere in the middle, keeps its own layers and is never mistaken for one, because the marker has to sit at the second to last underscore specifically.

Reading a save while the server writes one

The Map screen reads the world file directly, and a running server can save at any moment. The reader handles that.

For a 1.0 world: if a chunk file disappears mid read, the reader checks whether a newer generation has since been committed. If one has, that was a save landing, so it reads the new generation once and says nothing. If the same generation is still the newest, the file genuinely broke and it reports damage.

For a legacy world: the .db is briefly absent during the atomic swap, so the reader waits 250 ms and tries once more.

There are also hard ceilings, so a corrupt length field cannot make the app allocate the machine's memory: a save file or chunk file over 256 MB, a compressed zone block over 256 MB, a decompressed one over 1024 MB, a single byte array field over 128 MB, a string field over 64 MB, a chunk claiming more than 50,000,000 objects, an explored bitmap over 64 million cells, or more than 100,000 map pins are all rejected as corrupt rather than read.

The biome cache

Valheim writes {world}_biomedatacache.bin into a cache folder beside the save folder. It belongs to the game, not to BakaLoader, and nothing in the app reads it.

It matters only when a world is copied, renamed or deleted, because the cache has to travel with the world or be removed with it. BakaLoader keys it on the world name stored inside the .fwl or .fwl2, not the name of the file on disk, because those two can differ after a copy or a rename. In 1.0.1 that key was corrected to match how the game itself keys the file.

Moving worlds by hand

Stop the server first. Copy the whole world folder for a 1.0 world, or both the .fwl and the .db for a legacy one, into the target profile's worlds_local. Copy the backup layers too if you want them.

BakaLoader refuses to copy a world into a folder that already holds one of the same name, and tells you:

A world called 'Midgard' is already in that save folder. Copying onto it would mix the two saves together, so nothing was copied.

It also refuses to copy a world into the folder it already lives in, which would have been the world destroying itself, and it refuses a folder of that name at the destination rather than clearing it unless you explicitly asked to overwrite. When an overwrite is asked for, every file is staged beside the destination and checked for length before anything at the destination is cleared, so a copy that fails part way through leaves what was there untouched.

If you do that by hand instead, nothing stops you, and you get two save histories interleaved in one folder. Rename one of them first.

Questions people ask

Can I go back to a pre-1.0 server after converting? Not with the converted world. You can restore the PRE-1.0 ORIGINAL layer and run that on the old build, but everything played since the conversion is in the 1.0 folder, not in that layer.

Why is my world folder so much bigger than the old .db was? A 1.0 world is chunked, so a save writes only what changed, but every kept generation and every automatic backup is a full set of files. Look at the size column in the Barrow.

A world vanished from the list. Two likely causes. Its name matched the backup test, so it is being shown as a layer under another world. Or a legacy pair is being shadowed by a folder of the same name. Open the save folder and look.

Does BakaLoader ever write into a world folder? It writes backup copies beside the world, and it writes the world back during a restore. It never edits a live world file in place.