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.
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 and remains read-only here because licensing and broad current-version round trips are unresolved.
- 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 | 37 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 | Read-only diagnosis | Locked: Oodle and round-trip gate |
| 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, placement, ownership, unique weapons and armour, guild membership, base position, and map fog stay read-only.
| Area | Operations | Stored in |
|---|---|---|
| Pals (19) | 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 | Level.sav |
| Your character (6) | Level, experience, name, work speed, sanity, fullness | Level.sav |
| Inventory (4) | Stack quantity, add an item to a free slot, remove an item, move a stack between containers | Level.sav, with ownership from Players |
| Progress (4) | Technology points, unlocked technologies, Paldeck registration, fast travel | Players/<id>.sav |
| Guilds (2) | Guild name, camp level | 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. GPL implementations can be used commercially only while meeting their source and copyleft obligations; other code or binaries have unclear or education-only terms.
That licensing problem is separate from correctness. Decompression only exposes GVAS and Palworld RawData. The writer still needs bounded parsing, full input consumption, stable serialization, and current-game testing. Pal Save Editor therefore recognizes PlM and explains the block instead of presenting a guessed export button.
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 37 published operations enter PlZ Beta; all other claims need separate evidence.
Why is PlM blocked?
No reviewed browser path currently meets this product's licensing, bounded parsing, and round-trip gates together.
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.