Older versus newer snapshot
Palworld save diff starts with two complete world snapshots.
A useful Palworld save diff answers what changed since the older snapshot, which changes look like normal play, and what important data may need review. The browser compares JSON fixtures at field level and two real binary snapshots at file-evidence level. It does not parse real binaries into player, Pal, inventory, identity, or ownership deltas.
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 save diff: what to know first
- Keep an older baseline and a newer complete WorldID or WGS snapshot; do not mix Level.sav and Players files from different write points.
- Treat level gains, elapsed world days, new catches, and explained item use as normal progress, while identity changes, ownership drift, and unexplained high-value removals need review.
- Match players, Pals, guilds, and bases by stable identifiers and references before using display names or array positions.
- A fixture receipt can prove semantic model changes; a real-binary receipt proves file-level evidence only. Neither proves that a snapshot loaded in the current game.
Start with two coherent Palworld snapshots
The older snapshot is the baseline and the newer snapshot is the observation. Both should come from the same WorldID and include the matching Level.sav, Players directory, metadata, world options, and any platform container needed to interpret them. Stop the game or server before each copy so the files represent a coherent write point.
Record the platform, game version, local time, file count, total bytes, and source hashes for both sides. A newer Level.sav paired with older player files can produce a dramatic diff that is really a mixed snapshot, not player progress or corruption.
| Evidence | Older baseline | Newer snapshot |
|---|---|---|
| World scope | Complete matching world or WGS copy | Complete matching world or WGS copy |
| Time | Known last-good or previous session | Known later copy after play, edit, or transfer |
| Identity | WorldID and player candidates | Same world plus expected identity changes |
| Integrity | File roles, sizes, signatures, hashes | File roles, sizes, signatures, hashes |
Separate normal progress from suspicious change
A session naturally changes many records. Player levels can rise, world days advance, new Pals appear, technology points fall as recipes unlock, and inventory moves between a player, base storage, crafting queues, and consumption. A useful report summarizes those outcomes instead of presenting every changed counter as a warning.
Suspicious does not mean corrupted. A missing high-level Pal may have been condensed, released, traded, or moved into another system. A large item decrease may be crafting or consumption. Flag changes that deserve confirmation and preserve the exact evidence without inventing a cause.
| Change | Initial classification | Question to answer |
|---|---|---|
| Levels, catches, Paldeck, or world days increase | Normal progress | Does the amount fit the elapsed play session? |
| Technology points fall while recipes increase | Likely explained | Were the points spent on those unlocks? |
| Item or money total changes | Context required | Was it crafted, consumed, sold, moved, or lost? |
| PlayerUID, GUID, guild, or owner changes | Identity review | Was a transfer or host migration intended? |
| High-value Pal, base, or player record disappears | Recovery review | Does the record exist under another identity or snapshot? |
Match identity and ownership before display names
Display names can be duplicated or changed, and collection positions move when records are added or removed. Player comparisons need PlayerUID, GUID, file role, and world references. Pal comparisons need a stable instance identity plus owner, container, party, base, or guild references where those structures are available.
Ownership changes are often more important than value changes. A Pal can keep the same level and skills but become stranded under an unexpected player identity after migration. A base or storage lock can remain present while pointing at the wrong owner. The report should show the identity path before interpreting the outcome.
Report changed and unchanged scope
A trustworthy diff names what stayed stable as well as what moved. If the comparison follows a one-Pal edit, it should confirm whether other Pals, players, guilds, bases, inventories, technologies, and world options remained semantically unchanged. If it follows a migration, expected identity rewrites should be separated from unrelated progression changes.
Exact field paths remain useful for technical review, but the first view should group changes by human object and consequence. Ambiguous records belong in an unresolved group rather than being forced into added, removed, or corrupted labels.
- Count changed and unchanged objects, not only changed fields.
- Separate expected task scope from unrelated changes.
- Keep ambiguous identity matches visible and block confident conclusions.
- Describe inventory totals as net change when transfers inside the world cannot be distinguished.
What the browser diff can prove today
The two-snapshot intake compares older and newer Pal Save Editor JSON fixtures semantically, grouping exact paths as progress, inventory, Pal, world, or identity evidence. The editor's change-plan diff still uses scope lock to reject fixture changes outside the visible controls.
Two real PlZ, PlM, CNK, raw GVAS, or unknown binary inputs can also be compared, but only by file role, path, size, signature, and SHA-256 evidence. The report deliberately does not claim levels, roster, inventory, identity, ownership, or corruption causes because those game records remain unparsed.
Keep a Save Diff Receipt and verify in game
For JSON fixtures, a useful Save Diff Receipt can record source hashes, exact paths, semantic groups, identity matches, expected scope, non-target results, and validation status. For real binaries, the current receipt is intentionally narrower: snapshot totals plus file paths, roles, sizes, signatures, hashes, additions, removals, and changed files. The original snapshots remain the recovery evidence behind either report.
Structural validation only proves that the parsed models and comparison rules behaved as recorded; it describes differences, not whether a snapshot is healthy. Check players, Pals, guilds, bases, inventory, technology, and map state as a separate confirmation.
- 01
Freeze both snapshots
Keep complete older and newer copies outside the active save path.
- 02
Verify comparable scope
Confirm WorldID, platform, versions, file roles, and matching write points.
- 03
Classify changes
Separate normal progress, expected task scope, suspicious changes, and unresolved identity matches.
- 04
Retain the receipt
Keep hashes, matching rules, changed and unchanged scope, and recovery locations together.
- 05
Confirm in the current game
Load only a test copy and record the objects and accounts actually verified.
Task checklist
- 01Use complete older and newer snapshots from the same world.
- 02Confirm both file sets represent coherent write points.
- 03Match stable identity and ownership before names or positions.
- 04Separate normal, suspicious, expected, and unresolved changes.
- 05Keep source hashes with each snapshot.
Questions people ask before touching the save
Can Pal Save Editor compare two real Palworld saves today?
Yes at the file-evidence level: paths, roles, sizes, signatures, hashes, additions, removals, and changed files. It does not parse those binaries into player, Pal, inventory, identity, or ownership changes.
Does a removed Pal mean it was lost?
Only a semantic JSON fixture comparison can identify a removed Pal record today, and even then it does not prove why the record disappeared. Real binary comparison can show that a file changed or disappeared, but cannot identify Pal-level removals.
Can a save diff prove the newer save will load?
No. A diff shows what changed between two snapshots: a fixture diff proves model changes, and a real-binary diff proves file-level evidence. Whether a snapshot is healthy is a separate check.
Why list unchanged objects?
Unchanged players, bases, guilds, Pals, inventories, and options show whether a narrow edit or migration stayed inside its intended scope.