SNES SRAM exports do not carry a universal schema describing which offsets represent game values. Phase 35 therefore exposes a transparent raw-byte patcher instead of fabricating semantic fields. Every write is supplied by the user, bounded before mutation, and applied to a copy in memory. The original file is never rewritten in place, and the output retains exactly the original length.
Emulator & Retro Tools
SNES Save Editor
Apply explicit bounded byte patches to a raw SNES SRAM copy while preserving file length exactly and refusing overlapping or out-of-range writes.
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.
No output has been built in this session.
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
Platforms
SNES
Supported versions / editions
Raw SRAM byte arrays selected from a known SNES/emulator context. SaveEditor does not infer cartridge mapping, title, variable schema, or checksum rules from the SRAM file alone.
Input constraints
Input must be a non-empty raw SRAM file no larger than 512 KiB. A patch plan may contain at most 64 operations and 4096 total written bytes. Each line uses offset: AA BB syntax; offsets must be in range and operations may not overlap.
Known limitations
This is a bounded byte-level editor, not a universal game-value editor. It does not locate money/stats automatically, resize SRAM, alter save states, reconstruct cartridge headers, or regenerate game-specific checksums unless a future verified game profile supplies those semantics.
Output / result
A new .srm copy with only the explicitly requested byte ranges changed. Output length is identical to input length.
03 / Instructions
Use a reversible workflow.
File-oriented workflows start with an untouched original. Tool-specific instructions add only details documented for this utility.
- 01Keep the original
Preserve an untouched copy before creating or transforming binary output.
- 02Confirm scope
Match the file size, format, platform, and version to the support information on this page.
- 03Process locally
Use the runtime only when the page reports that its declared engine is loaded.
- 04Validate output
Compare or test the result before replacing any working source file.
Tool-specific steps
Choose a backed-up raw SRAM file, enter one or more byte patches such as 0x10: FF 00, apply the plan, review the number of written/changed bytes, and download the new copy. Keep the original and verify game-specific checksum requirements separately.
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
Phase 36 reads a selected file only after explicit local file selection. Parsing, inspection, normalization, extraction, and supported conversions run in the browser. The emulator-retro runtime contains no fetch, XMLHttpRequest, WebSocket, or sendBeacon calls. The shared file ceiling is 16 MiB, with stricter format-specific limits where appropriate.
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.
Re-check the documented input type and browser size limit before retrying.
A generic converter does not imply support for every game-specific container, signing scheme, or serialization format.
Return to the untouched source instead of repeatedly processing a damaged or partially transformed file.
Known Tool issues
Out-of-range offsets, malformed hex, overlapping operations, excessive patch plans, and empty files fail closed. If the target game maintains internal checksums, a generic raw byte change may be rejected by the game; use a verified game-specific profile when available.
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.
Method notes
Verified with bounded parser tests for decimal/hex offsets, exact byte diffs, immutable source bytes, preserved length, overlap rejection, bounds rejection, malformed-plan rejection, and strict operation/write ceilings. The capability claim is deliberately byte-level only.
Public references
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 SNES Save Editor ready to use?
Does processing stay in the browser?
Should I keep the original file?
What if my input is rejected?
Related tools
Continue with the same tool family.
Only index-ready verified records from the same Tool Family are shown here.
Related guides
Read the guidance connected to this tool.
Only reviewed, index-ready Guides that explicitly reference this Tool are included.
Backups & Safety
SNES SRAM Backup & Identification Guide
A safety-first SNES SRAM guide for identifying the intended representation, preserving an untouched source copy, and choosing only a verified compatible Tool.
Save File Formats
SNES SRAM Integrity & Troubleshooting Guide
A fail-closed SNES SRAM troubleshooting guide for distinguishing representation problems from unsupported semantics and for selecting read-only integrity checks before any repair attempt.