find your wildmender save folder. for most people it'll be in C:/Users/{your username}/AppData/LocalLow/Muse Games/Wildmender/worlds. the worlds are folders, each generally named WildmenderWorld{number}. open the folder for the world you want to load and select (shift-click) all of the chunk_{number}_{number} files. you can also select the metadata file too if you want; that's where player data is located. it'll take a bit to load all the chunk data.
all of the map decoding happens client-side; i'm not storing or seeing your files in any way. (saves do include your steam name in the player data; maybe the steam name of anybody you ever played multiplayer with.) this also means that you can save a local copy of the map viewer if you want and use it yourself. just download this page plus this gzip library file.
the layout & functionality is still pretty patchy!
this (maybe?) doesn't work with saves from the demo; there were apparently at least minor changes in the savedata format between the demo and the current version. if there are any future savegame format changes in the future (we can only hope), that will also probably break it.
first, all the files are gzip archives. if you want to look at them yourself, all you really need to do is rename one to {filename}.gz and then open it up with a robust-enough archiving program. linux command-line gunzip works fine; idk what else does. they appear to have something beyond a raw gzip archive in there, though -- a bunch of common programs and utilities fail to open them, because there's an invalid chunk in there. (the way gzip compression works is that you can just mash two gzip binary files together to get a gzip binary with two files in it. but it's also totally legitimate to make a gzip file that has other misc information in it -- checksums, library stuff, w/e -- after a valid chunk, and the protocol is supposed to ignore those. in practice, a lot of tools see anything else coming after a valid gzip chunk and go 'this must be another gzip chunk' and then error out when it's not, which is why some programs have difficulty decoding these files.)
anyway, i have absolutely no clue what else is in the gzip files! it could be anything or nothing. i don't think it's critical, since custom gzip files still work, so i don't think there's anything special about the gzipping process.
the actual chunk data opens with a 4-byte header, 09 00 00 00. no clue what that means, if anything. after that there's 00 00 01 00 (65535), which is the length of the upcoming array. so: right after that we have a 65535-item array: 256 * 256 * 7 (= 458752) bytes of heightmap information.
these heightmaps are interleaved as three 16-bit heightmaps and then a 8-bit heightmap -- a bedrock heightmap, a water depth heightmap, a diggable sand layer, and then something i'm calling the 'material' heightmap. that one (i think) stores things like ground texture, something to do with wet soil, maybe salt/poison information, maybe soil fertility; that's the main thing i haven't figured out yet. all the other heightmaps are just, well, a heightmap: larger numbers means more of the thing. the heightmaps are structured with +x going to the east and +y going north; they start at the southwest corner of a chunk and proceed east and then north.
after that, at byte offset 458760/0x70008, there's a four-byte 04 00 00 00 value that i assume is another array length value (64), followed by 8 * 8 * 20 (= 1280) bytes of biome data. each biome cell is laid out as, i think, five 4-byte int values: two numbers, which i haven't fully understood, and then three biome flags. third and fifth biome flags are just biome ids: current biome (3) and underlying biome (5). when e.g., wasteland spreads, biome mothers are established, etc, it does so by changing the current biome. the fourth value is just 1 in the salt flats, 2 in the canyons, and 0 everywhere else; that might be related to the thirst/poisoning status for those biomes, or work as a trigger for when those 'you're entering the salt flats/canyons' messages pop up; i don't really know. the first two numbers are usually 0, but they're non-zero when there's some kind of biome activity going on -- i think one is related to biome spreading and the other biome receding, but i'm really not very sure at all. i think something else might be encoded in the high byte of those (they might not be 4-byte values at all, but some packed struct of smaller values), but i really have no clue.
after that, at byte offset 460044/0x7050c, we hit a bunch of JSON object data, as plaintext. this is basically a list of every object spawned by the chunk, which have their own internal double-serialized state values. i don't really know much about them aside from a handful of relevant values -- there's CultivarId for a numeric cultivar id, and Soulless for plants killed by wasteland that don't glow at night. presumably there are many other important values. anyway, this serialized json chunk is of varying length and continues until the end of the file.
tantalizingly, the game doesn't seem to have any checksums or hashes or fiddly library encodings that would stop somebody from just generating a whole custom map. from some simple tests, it seems like the map size is fixed at a 12x12 chunk grid starting at -6,-6 and going to 5,5; i don't know if it's feasible to try to mod that or anything. there is a ChunkSize attribute in the metadata that's set to 256, but i wouldn't expect changing that to work well -- knowing how game development goes, though, muse games totally could have fixed that once they decided on a map size and now it's an assumption baked in to a lot of other code that will totally break things if it changes.