What's inside an Enshrouded .ksd save file (and how I parse it in the browser)

Foolgry Wang — Sat, 31 Oct 2026 16:59:59 +0000

If you've put serious hours into Enshrouded, at some point the save file starts to feel personal. You want to re-plan a skill build without redoing the grind, an item vanished after a crash, you're moving a character between a local world and a dedicated server, or a big patch is coming and you want a known-good backup first.

All of that lives in one place: a .ksd file on disk. It has a reputation for being opaque, mostly because opening it in a hex editor shows you compressed noise. But it's a small, layered container, and it's quite parseable. This post is a walk through what's inside and how I built a parser for it that runs entirely in the browser.

Why open the file at all

Games usually give you sanctioned ways to fix things. Enshrouded gives you some, but not everything:

Respec options are limited. Sometimes you want to re-plan a long-running character from scratch, not incrementally.
Bugs eat items. Crashes and patch migrations have been known to take inventories with them.
Local vs. dedicated server. Character data lives in a file you own, and moving it between setups is a common desire.
Backups before patches. The most boring and most valuable use case: keep a copy you can roll back to.

A hex editor technically works for peeking, but since most of the payload is compressed, it tells you almost nothing. To do anything useful you have to unpack the container first. And once you have a working parser, the friendliest place to run it is the browser: no installer, no platform questions, and nothing has to be trusted with your save.

The container, in layers

A .ksd file is not a flat dump of game objects. It's a small archive, and it helps to think of it in three layers.

Layer 1: a container header. The first bytes describe the file itself: format markers, version-ish fields, and how the rest of the file is laid out. I'm deliberately not going to quote byte offsets or magic constants here. They're exactly the kind of detail that rots between patches, and hardcoding them is the mistake that killed my first parser.

Layer 2: length-prefixed, compressed sections. After the header, the file divides into sections. Each section starts with its length, and the payload is compressed. The pragmatic move is to identify the compression empirically — by sniffing the payload — rather than trusting a single constant from an old forum post. Once a section is inflated, you're holding actual game data.

Layer 3: the object tree. The decompressed payload is a serialized tree of game objects: entities with property lists, type tags, and nested structures. IDs cross-reference each other. Your character is one such object; inventory, equipment and skill data hang off it, sometimes several levels deep, sometimes referenced from more than one place.

Two consequences follow from this shape. First, nearly everything interesting is unreadable until you inflate the right section — which is why hex-editing a .ksd in place rarely works. Second, a parser should walk the structure instead of seeking to fixed offsets. Patches reshuffle the layout; a walker survives that far better than a seek table.

Parsing it in the browser: the decisions that mattered

1. Everything heavy lives in a Web Worker

Decompressing sections and walking a binary tree is exactly the kind of work that freezes a main thread: the tab goes grey, the spinner stops spinning, and users assume the site died. So the whole pipeline — reading the File into an ArrayBuffer, walking the container, inflating sections, building the object model — runs in a worker. The main thread only receives small progress messages and the final structured result. The UI stays responsive mid-parse, which for a tool whose entire pitch is "trust us with your save file" turns out to matter more than you'd expect.

2. TypedArray and DataView, with a cursor

The binary layer is deliberately boring: a DataView over the buffer, an explicit byte order, and a cursor exposing helpers like readUInt32() and readLengthPrefixedString(). Sections are handled lazily — decompress one, wrap its bytes in a new view, keep walking. Nothing becomes real JavaScript objects until the UI actually asks for it, which keeps memory sane on larger saves.

3. Fail loudly, never guess

This is the principle I care about most. When the parser meets something it doesn't understand — an unfamiliar version, an unknown property tag, a structure that doesn't line up — it stops and reports where it stopped, instead of improvising. In this domain, the failure mode of "close enough" is a silently corrupted sixty-hour character, and that cost lands on the player, not on us. Writing follows the same asymmetry: the editor only re-serializes structures it fully understands and preserves everything else verbatim. Unknown means untouched.

Things that bit me

Fixed offsets. My first attempt seeked to hardcoded positions. The next patch reshuffled the layout, and everything past that point turned to noise. Walk, don't seek.
Cursor drift. One off-by-one in a length-prefixed string made every later field in the section parse as plausible garbage — worse than obviously broken data. Now every read validates its length against the bytes actually remaining.
Trusting labels over bytes. Assuming every compressed block uses whatever its header claims was too optimistic. Dispatching on the payload's own signature is far more robust.
Cross-referenced values. Some values appear in more than one node — the live one plus a cached or derived copy. Editing a single field and calling it done produced half-applied changes until I traced the references properly.

The tool

I ended up wrapping all of this into a free, browser-based save editor: enshroudedsaveeditor.com. No login, nothing uploaded — your file is parsed in a Web Worker on your machine and never leaves the browser, and any structure the editor doesn't understand is reported as an error rather than rewritten. It's in Beta, so the one rule that actually matters: copy your save file first, and edit the copy. Backups are free; characters are not.

If you've poked at .ksd files yourself — or you try the editor and it refuses a file you believe is valid — I'd genuinely like to hear about it in the comments. Details that survive patches come from real saves, and error reports are the most useful input there is.

DEV Community: Foolgry Wang