Skip to content
Game save workbench
Local-first tools No installation Support status shown
DEVICE-LOCAL Favorites and recent pages stay in this browser.

Save Editors

Slay the Spire Save Editor

Decode and safely rebuild a Slay the Spire desktop .autosave locally, with verified edits for gold, current health, and maximum health while leaving the deck, relics, potions, seed, and run structure untouched.

01 / Tool workbench

Use the runtime only when it is actually ready.

The application shell fails closed. An input interface is not enabled merely because a WordPress Tool record exists; the declared engine must be registered in the current build.

Slay the Spire Save Editor
BROWSER LOCAL

Checking whether the declared runtime module is loaded. No input has been processed.

Session change summary

No output has been built in this session.

What this game-specific editor changes

Decode and safely rebuild a Slay the Spire desktop .autosave locally, with verified edits for gold, current health, and maximum health while leaving the deck, relics, potions, seed, and run structure untouched.

Verified save contract

The selected file must be strict Base64 whose decoded bytes XOR with the repeating ASCII key "key" into valid UTF-8 JSON. The decoded object must contain integer gold/current_health/max_health/floor_num fields plus cards and relics arrays. Input is limited to 4 MiB.

Supported save family

Slay the Spire desktop .autosave Base64/XOR-key/JSON container family.

Deliberate limitations

Phase 26 does not claim support for Slay the Spire 2, profile/progression preference files, non-UTF-8 decoded payloads, mod-specific save schemas, beta filenames with different extensions, card/relic insertion, or arbitrary JSON tree editing.

Safe workflow

Close the game, back up the original .autosave, select the active character autosave, confirm the detected floor and current values, edit the exposed run fields, and download the rebuilt copy. Keep current health at or below maximum health.

Why SaveEditor fails closed

The Tool must match its exact bundled game profile before the workbench will launch. The original selected bytes are preserved, edits occur on an in-memory copy, and the generated output must pass the same profile/version validation after writing.

Verification basis

Verified with two encoded autosave fixtures, Base64/XOR/UTF-8-JSON round trips, structural-key fingerprinting, extension checks, malformed-container rejection, health-relation validation, exact preservation of unrelated decoded JSON bytes including Unicode, original-byte preservation, and post-write reopen validation. Public reverse-engineering implementations document the repeating "key" XOR plus Base64 format and common run fields.

02 / Compatibility

Know the supported input before opening a file.

Compatibility fields are intentionally explicit. Missing values stay unclaimed rather than being filled with generic assumptions.

Accepted extensions

.autosave

Platforms

PC

Supported versions / editions

Slay the Spire desktop .autosave Base64/XOR-key/JSON container family.

Input constraints

The selected file must be strict Base64 whose decoded bytes XOR with the repeating ASCII key "key" into valid UTF-8 JSON. The decoded object must contain integer gold/current_health/max_health/floor_num fields plus cards and relics arrays. Input is limited to 4 MiB.

Known limitations

Phase 26 does not claim support for Slay the Spire 2, profile/progression preference files, non-UTF-8 decoded payloads, mod-specific save schemas, beta filenames with different extensions, card/relic insertion, or arbitrary JSON tree editing.

Output / result

A separately encoded .autosave copy. The profile changes only the verified top-level numeric JSON spans for gold/current_health/max_health, preserving every unrelated decoded UTF-8 JSON byte before applying the repeating-key XOR and Base64 container encoding again.

03 / Instructions

Use a reversible workflow.

File-oriented workflows start with an untouched original. Tool-specific instructions add only details documented for this utility.

  1. 01Keep the original

    Preserve an untouched copy before creating or transforming binary output.

  2. 02Confirm scope

    Match the file size, format, platform, and version to the support information on this page.

  3. 03Process locally

    Use the runtime only when the page reports that its declared engine is loaded.

  4. 04Validate output

    Compare or test the result before replacing any working source file.

Tool-specific steps

Close the game, back up the original .autosave, select the active character autosave, confirm the detected floor and current values, edit the exposed run fields, and download the rebuilt copy. Keep current health at or below maximum health.

04 / Privacy and processing

The processing mode is part of the product contract.

SaveEditor.com should state local processing only when the implementation truly keeps file contents in the browser. Server or hybrid processing must be disclosed just as clearly.

Declared mode

Browser local

Runtime state

Operational

Tool-specific privacy notes

The selected save is read only after explicit file selection and processed entirely in the browser. Phase 26 profile scripts contain no fetch, XMLHttpRequest, WebSocket, or sendBeacon calls. The original bytes remain untouched; successful edits generate a separate downloadable copy after profile/version validation and post-write revalidation.

05 / Troubleshooting

When a file is rejected, do not force it.

A rejection can indicate an unsupported size, format, version, platform, or byte sequence. Preserve the original and correct the input instead of bypassing validation.

Wrong file or size

Re-check the documented input type and browser size limit before retrying.

Unsupported format

A generic converter does not imply support for every game-specific container, signing scheme, or serialization format.

Source was modified

Return to the untouched source instead of repeatedly processing a damaged or partially transformed file.

Known Tool issues

If detection fails, confirm the file is an original desktop .autosave rather than a preference/progression file or Slay the Spire 2 save. If the game rewrites the file after launch, restore your backup and verify that Steam Cloud or another sync client did not replace it.

06 / Verification

Support claims should be traceable.

The verification date, method notes, and public references are kept separate from marketing language so compatibility can be reviewed over time.

Last verified2026-08-08
Profileslay-the-spire-pc-autosave-v1

Method notes

Verified with two encoded autosave fixtures, Base64/XOR/UTF-8-JSON round trips, structural-key fingerprinting, extension checks, malformed-container rejection, health-relation validation, exact preservation of unrelated decoded JSON bytes including Unicode, original-byte preservation, and post-write reopen validation. Public reverse-engineering implementations document the repeating "key" XOR plus Base64 format and common run fields.

07 / FAQ

Questions to answer before editing.

These answers are generated from the Tool record and current runtime state rather than generic compatibility promises.

Is Slay the Spire Save Editor ready to use?
The Tool record is verified and declares an operational runtime. The page enables its input controls only when the declared engine module is loaded in the current build.
Does processing stay in the browser?
Yes for this declared mode. The loaded runtime processes the explicit input in the browser; Tool-specific privacy notes describe the exact scope and limits.
Should I keep the original file?
Yes. Keep an untouched source file until any generated output has been validated.
What if my version is not listed?
Treat unlisted versions as unverified. Do not assume two releases use identical save layouts, checksums, signing, or serialization.

Related tools

Continue with the same tool family.

Only index-ready verified records from the same Tool Family are shown here.