Evidence-based compatibility
Palworld 1.0 save compatibility by platform, format, and task.
Palworld 1.0 save compatibility cannot be reduced to a single supported badge. A tool may recognize PlM, decode an outer container, parse part of GVAS, and still fail to rebuild current RawData or load the export in game. Pal Save Editor reports recognition, reading, writing, and round-trip as separate stages so a read-only answer never appears as safe editing support. Oodle-compressed PlM worlds now pass every one of those stages and are editable; CNK, raw GVAS, and WGS still stop at recognition.
Open a save to see its world summary
We will identify the files, version clues, completeness, and tasks available for this exact input.
Compatible PlZ Beta worlds can expose named players and Pals; unsupported formats receive diagnostic evidence.Quick answer
Palworld 1.0 save compatibility: what to know first
- Post-1.0 issue reports show failures in specific RawData paths, proving some parsers need updates without establishing that every 1.0 save is affected.
- PlZ identifies a zlib container; only the documented PlZ Beta fixture and operation rows have passed the current write gates.
- PlM uses Oodle. It is decompressed in your browser by an open-source decoder, and the edited world is written back as a PlZ/zlib save, which the game also loads.
- Compatibility must name the platform, file type, task, parser version, and validation result.
Read the Palworld 1.0 save compatibility matrix correctly
Recognition finds a file role and outer format signal. Reading turns the required bytes into a structured model. Writing rebuilds the file. An unchanged round-trip proves the parser can decode and re-encode its model. A changed round-trip verifies selected edits. Actual game loading confirms the current Palworld build accepts the result.
Each stage can fail independently. For example, a PlM marker is easy to recognize, but decoding needs Oodle. Post-1.0 reports also show failures in specific Palworld RawData paths. That evidence means affected parsers need updates; it does not define a complete 1.0 schema change list or prove every 1.0 save is affected.
| Format or input | Recognize | Structured read | Binary write |
|---|---|---|---|
| Pal Save Editor JSON fixture | Yes | Yes | Yes, fixture safe pack |
| Qualifying PlZ2 / 0x32 world | Yes | Named players, Pals, inventory, guilds, and bases | 46 operations: Pals, players, inventory, progress, guilds, bases |
| Other PlZ Steam / server save | Yes | Capability-dependent | Locked when the exact operation is not evidenced |
| PlM Steam / server save | Yes | Named players, Pals, inventory, guilds, and bases | Same 46 operations; the export is written as PlZ |
| CNK Game Pass container | Yes | File-set diagnosis | Locked: conversion and identity gate |
| Unknown or truncated save | Fingerprint only | No | Blocked |
What PlZ Beta can write in a Palworld save today
Every writable operation has its own evidence row on a qualifying PlZ2 / 0x32 world: an unchanged round-trip, a changed reparse, a non-target comparison, and a browser run. Records in Level.sav need only that file; inventory needs the matching Players files to say which containers belong to whom, and progress lives in the player's own file.
A move between two containers is two slot writes applied as one undoable step, so an item can never be left in both places or in neither. Species, putting a Pal to work at a base, unique weapons and armour, guild membership, base position, and map fog stay read-only.
| Area | Operations | Stored in |
|---|---|---|
| Pals (23) | Level, experience, HP / Attack / Defense / Melee IV, work speed, sanity, fullness, condensation rank, HP / Attack / Defense / Work speed souls, gender, nickname, passive skills, equipped moves, mastered moves; copy into the owner's Palbox, remove, move between party and Palbox, give to another player | Level.sav; copies, removals, and moves need the owners' Players files |
| Your character (8) | Level, experience, name, work speed, sanity, fullness, status points, unspent status points | Level.sav |
| Inventory (5) | Stack quantity, add an item to a free slot, remove an item, move a stack between containers, base chests and shelves | Level.sav, with ownership from Players |
| Progress (5) | Technology points, ancient technology points, unlocked technologies, Paldeck registration, fast travel | Players/<id>.sav |
| Guilds (3) | Guild name, camp level, leader | Level.sav |
| Bases (2) | Base name, radius | Level.sav |
Why PlM and Oodle change browser support
Palworld moved many saves from PlZ/zlib to PlM/Oodle starting around version 0.6. Browser tools distribute a WebAssembly decoder to visitors, so each component's license and provenance become part of the product. The only open Kraken decoders are GPL-3.0, which may be used commercially while their source and copyleft obligations are met; other code and binaries have unclear or education-only terms.
Pal Save Editor meets those obligations the direct way: the decoder is vendored with its own source, and this editor's source is published under the same license. Decompression alone was never the whole problem - the writer still needs bounded parsing, full input consumption, stable serialization and current-save testing - and each of those has its own evidence row. The edited world is written back as a PlZ/zlib save, which the game loads and replaces with its own compression the next time it saves.
What Palworld 1.0 changed for save tools
Current GitHub reports show `EOF not reached` failures inside specific Palworld RawData paths after 1.0, including work assignment structures. This proves outer-format support alone is insufficient and that some parsers need updates. It does not establish a complete schema change list or prove every 1.0 save is affected.
A draft Palworld integration for the MIT `uesave` project reports unchanged round-trip testing across 261 real saves. The pull request is still a draft, its current WebAssembly wrapper is not a finished Palworld browser product, and enabling its optional Oodle dependency changes the resulting binary to GPL. Those caveats matter as much as the reported test count.
How Palworld save compatibility should be tested
Compatibility testing needs representative real saves for each platform, outer format, file role, world size, multiplayer shape, and task. The test record should include game version, parser commit, fixture hash, expected objects, unchanged round-trip result, changed reparse result, non-target comparison, and actual load confirmation.
Failures should remain visible in the changelog. Hiding unsupported versions encourages users to replace files based on a green badge that no longer matches the current game.
- 01
Identify the exact input
Record platform, file role, PlZ, PlM, CNK or GVAS, declared size, and game version.
- 02
Consume the full structure
Reject trailing bytes, unknown required fields, excessive allocation, and broken references.
- 03
Prove unchanged round-trip
Rebuild an untouched model and compare decompressed bytes or a documented semantic equivalent.
- 04
Prove scoped edits
Reparse the changed export and verify only approved paths or regions changed.
- 05
Confirm in the current game
Load the export and verify affected and unaffected players, Pals, bases, guilds, and options.
Task checklist
- 01Check outer format and inner GVAS separately.
- 02Require current-version fixtures for edit claims.
- 03Treat decode-only support as read-only.
- 04Keep the original backup with every exported change.
- 05Keep unsupported versions visible instead of silently guessing.
Questions people ask before touching the save
Does PlZ mean my save is safe to edit?
No. PlZ identifies the outer compression path. Only a qualifying PlZ2 / 0x32 world and the 46 published operations enter PlZ Beta; all other claims need separate evidence.
Is PlM supported?
Yes. An Oodle-compressed save is decompressed in your browser, edited through the same gates as a zlib save, and written back as PlZ, which Palworld also loads.
Is Palworld 1.0 automatically compatible?
No. Post-1.0 issue reports show failures in specific RawData paths, but each task and format still needs direct evidence against representative real saves.