Treat a 7 Days to Die campaign as a world directory, not one player file. Back up the full game-save folder and retain the matching generated world/mod context before upgrades.
Known 7 Days to Die save-file structure
The researched filename or folder pattern is generated-world/game folders with player .ttp data and world-state files. File-extension context: .ttp The documented format notes are: 7 Days to Die saves are multi-file world directories. Generated world data and the save instance are related but distinct, and mods/game version can affect compatibility.
Why an extension is not enough
A save filename can identify a likely container, but it does not prove the internal schema, game version, checksum rules, encryption state, or editability. Treat saves as version-, storefront-, account-, and mod-sensitive unless the game or a separately verified migration workflow proves otherwise. A similar filename or extension is not evidence that two releases are interchangeable. SaveEditor therefore separates file identification from Tool compatibility and only labels a game-specific Tool Verified when its exact profile/version evidence passes the runtime gate.
Where the format is stored
PC save locations: Windows: %APPDATA%7DaysToDieSaves. Storefront context: Steam, Microsoft Store. The active Steam, Microsoft Store installation determines which local profile and cloud copy can overwrite the save. Identify the storefront and account before restoring files. This matters because two releases can use different containers or companion files even when the visible slot name is similar.
Back up before inspecting or editing
Close 7 Days to Die, let the launcher finish any synchronization, then copy the complete documented save directory to a dated folder outside the live path. Preserve companion files rather than selecting only the newest-looking record. A read-only viewer is lower risk than a writer, but the live save should still be copied first. Cloud context also matters: Cloud behavior is storefront-dependent; manual world/save backups are recommended before major version changes. Keep the original bytes available so any experiment can be reversed without relying on a cloud service or automatic backup.
What this reference does not claim
This page does not infer an undocumented checksum algorithm, encryption key, compression layer, or cross-store conversion from the file extension. Troubleshooting evidence: If progress is missing after a restore, confirm the active Windows account, storefront/profile, cloud state, and exact directory first. Restore the untouched backup before experimenting with individual files or older autosaves. Those questions require a verified parser/profile or a game-specific source, not a generic format guess.
Verification context: Windows save location, file-boundary, launcher/cloud, and backup notes were reviewed against the linked game-specific references for 7 Days to Die. This Game Hub is documentation only and does not claim a new game-specific Save Editor.
Recorded Phase 40 evidence boundary
This Phase 40 entry is grounded in the researched PC save boundary for 7 Days to Die: Windows: %APPDATA%7DaysToDieSaves The recorded file or folder pattern is generated-world/game folders with player .ttp data and world-state files. These concrete identifiers are retained so backup, transfer, recovery, and editing preparation remain tied to the documented game/storefront context instead of a generic extension guess.