SaveState: a game save backup manager for Windows and Linux

The problem, and the promise of no configuration

SaveState is a user-friendly GUI for Windows and Linux to back up and restore video game save files, and the readme names the situations it is for: games without cloud saves, managing multiple save locations, and syncing progress across devices.

The first requirement of the design is stated in a blockquote with some force. Zero Configuration Required. Download, run, and start backing up. No config files to edit, no setup wizard, no account needed. And then the instruction that follows is the sharpest sentence in the readme: if a guide tells you to configure SaveState before using it, that guide is wrong.

That is a strong claim, and it tells you what kind of project this is. The hard part of game save backup is not the zipping, it is finding the save folder in the first place. A game might store saves in the Steam userdata directory, or in AppData, or in a hidden folder next to the executable, or somewhere a publisher decided on. A tool that requires you to specify paths has not saved you any work, and a tool that requires a config file has a setup step that users will fail at.

So the central trick is auto-detection, and it is what the rest of the readme describes.

There is a second guarantee, again stated as a warning. No Admin Rights Needed. This app does NOT require administrator privileges. If Windows asks you to run it as admin, don't. Something is wrong.

Both of those are user-experience decisions dressed as technical requirements, and both matter for a tool that people install to protect something they care about. A backup utility that demands elevation teaches users to accept elevation prompts from a program that has no business having them, and the readme is right to make a point of it.

The project is Python with PySide6 for the interface, GPL-3.0, and the recent releases are v3.1 from 2026-09-30, v3.0 from 2026-08-01 and v2.9 from 2026-07-14, with the last push on 2026-10-13.

Adding a game and finding the save folder

The headline interaction is one drag. Drop any launcher shortcut onto SaveState and it finds the save folder for you, and the feature list expands the range of launchers it accepts: Steam, Epic, GOG, Battle.net, Ubisoft, EA App, Playnite, Heroic, and more.

That is the right input for the job. A launcher shortcut contains the game identifier and the store, which is exactly the information needed to compute the likely save path, and it is information the user already has in the form of an icon on their desktop.

The finding itself is layered, and the readme names the layers. Smart save detection means Steam awareness, deep scan, and fuzzy matching when paths aren't obvious. Steam awareness comes first because the Steam userdata layout is well known and covers a large share of the library. Deep scan is the fallback for games outside the store ecosystems. Fuzzy matching is the last resort, and the requirements show the library for it, thefuzz, alongside vdf for reading Valve's data format and nbtlib for Minecraft's NBT format.

That dependency list is a good summary of the scope. vdf is the key-value format Valve uses for app manifests and configuration, so reading it is how you know which library a game is in. nbtlib is the NBT format Minecraft uses for its worlds, so a game with a directory full of NBT files is recognisable by its contents rather than its path.

Fuzzy matching is where the design gets interesting, because it is the difference between a tool that works on the games the author tested and one that works on the games you play. There is a dedicated documentation page for it, How Save Search Works, with heuristics and a flowchart, and the fact that the heuristics are documented rather than hidden is a good sign.

The quick start confirms the zero-configuration claim. Launch the app and the defaults work out of the box, drag a game shortcut onto the window or use Manage Steam or New Profile, then select a profile and hit Backup or Restore. Settings exist for the backup folder, cloud sync and per-profile limits, and right-clicking a profile gives more options.

Emulator support, and the two cases with unusual depth

The emulator table is the widest part of the feature set, and it lists RetroArch, Ryujinx, Yuzu, Rpcs3, Dolphin, ares, DuckStation, PPSSPP, Citra, Azahar, mGBA, Snes9x, DeSmuME, Cemu, Flycast, ShadPs4, SameBoy, PCSX2, Xenia, Eden, melonDS, Gopher64, Citron, Vita3K, Mednafen, ymir, xemu and KytyPS5, with a star marking the ones that have enhanced integration with guided setup.

RetroArch, Dolphin and ares carry the star, and that is a sensible allocation because those three are the emulators a large number of people actually use and because their save layouts are the messiest. RetroArch in particular stores saves per core in a directory structure that varies by version.

Two entries have their own footnote, and both footnotes describe work that went well beyond calling a library.

The PlayStation 2 memory card functionality in SaveState utilizes and adapts code from the mymcplusplus project, which is based on mymc+ by Florian Märkl and the original mymc by Ross Ridge, distributed under the GNU General Public License v3.0, and SaveState including these derived components is also licensed under GPLv3. A PS2 memory card is a specific binary format with save slots, and implementing it from scratch would be a large job, so reusing an existing GPL implementation is the sensible engineering decision.

Original Xbox support through xemu uses a surgical QCOW2 and FATX backup engine developed for this project, with the research lab, method notes and engine published separately as xemu_tools by the same author. The parenthetical is the striking part, that it works on hard disk drives where a game was never launched. That is a claim about forensic-level image handling, and publishing the method notes separately is how you let someone check that claim.

The general emulator list also matters for a practical reason. A save backup tool is only useful if it covers the games you play, and the fact that the list includes emulators rather than only store games says the author expects a substantial part of the user base to be running emulated titles, which is also why Steam Deck is in the topic list.

Backups, cloud sync and the install story

The backup behaviour is straightforward and the two details worth knowing are the format and the rotation. One-click backup and restore uses compressed .zip archives with automatic rotation, and the readme mentions zip rotation again in the repository description alongside optional cloud sync.

Rotation is what keeps a backup tool from filling your disk, and doing it automatically means the user does not have to remember to prune old archives.

Cloud sync is optional and the provider list is broad: Google Drive, WebDAV, FTP/FTPS, SMB/NAS, or Git. Git is the odd one out and the most interesting, because a Git remote is a perfectly good backup target for small text and configuration files, and using it means the backup history is inspectable with tools most people already have. The dependencies back up the Google Drive story, with google-auth-oauthlib, google-auth-httplib2 and google-api-python-client all present.

The rest of the feature list covers per-profile settings, minimize to tray, portable mode, and a Linux AppImage, which are the details that decide whether a background backup tool is something you tolerate or something you switch off.

The installation story differs by platform and is worth reading carefully, because the Windows path is unusual. Windows is recommended: download SaveState_vX.X.X_Win.zip from Releases, extract, and run, with no installer. Or install it via WinGet with winget install Matteo842.SaveState.

For Linux you download SaveState.tar.gz, extract the AppImage, and then:

chmod +x SaveState*.AppImage
./SaveState*.AppImage

Building from source is documented separately in docs/Building-from-Source.md, and the requirements file gives a sense of the scale. PySide6 for the interface, winshell and pywin32 on Windows only, pynput for input handling, vdf and nbtlib for the file formats, thefuzz for matching, psutil and requests for the network and process work, and notify-py for native Linux notifications.

The packaging side shows how the two platforms are produced. There are SaveState-OneFile.spec and SaveState-OneFile-Linux.spec, which are PyInstaller specification files, one per platform, and a packaging/ directory alongside them.

The project is signed through the SignPath Foundation, which provides free code signing for open source, and the artefact is signed by SignPath.io using a certificate from the foundation. For a program that asks for access to your game directories, having a verifiable signature is a reasonable thing to want.

Documentation, feedback and the project boundaries

A few details about how the project is run are worth knowing before you decide how to engage with it.

The documentation is split across four pages and the readme is explicit that this is deliberate, saying more detail without bloating this page. There is Usage for profiles, restore, launchers and UI screenshots, Cloud Sync for the providers and their setup, How Save Search Works for the heuristics and a flowchart, and Building from Source covering the Python side and the dependencies.

The split by audience is sensible. Each of those pages answers a question a different person has, and putting them in separate files means a user looking for the save search flowchart does not have to scroll past the install instructions.

Then there is the contribution policy, and it is the one thing in the readme that will surprise you. Feedback and ideas go to Issues. Code PRs are not accepted; see CONTRIBUTING.md.

That is an unusual position for an open source project, and it deserves a moment's thought. For a project with a broad, messy problem domain, the hard part of the work is not code, it is discovering which save paths exist and what their edge cases are. An issue that says this game stores its saves in an unusual place is directly actionable, and a pull request that adds a path is a much smaller contribution than the person who found the path.

The same pattern shows up in the xemu footnote. Rather than only shipping the engine, the research lab, the method notes and the engine itself are published separately as xemu_tools by the same author. The same author also publishes SaveState for Android as a separate repository, and there is a Discord server and a Ko-fi link for support.

There is also a legal section that goes beyond the licence, with a privacy policy and terms of service hosted alongside the project, plus a SECURITY.md, a CODE_OF_CONDUCT.md and an API_KEY/ directory at the top level, which is where the credentials for the cloud providers live.

The licence is the GNU General Public License v3.0, and the readme notes the derived components explicitly. The PlayStation 2 memory card code comes from mymcplusplus, which is based on mymc+ by Florian Märkl and the original mymc by Ross Ridge, all under the GPL v3.0, and SaveState including those derived components is also GPLv3. Since the project already had to be GPL to absorb that code, the licence choice was forced, and saying so openly is better than leaving a user to discover it.

Editorial conclusion

Adopt SaveState if you play games without cloud saves, or you juggle several installations and want one backup tool that covers the whole library rather than a per-game utility. Do not adopt it if you expect the project to accept code contributions, because the readme says code pull requests are not accepted and asks for issues instead. Before you commit, note that the Windows build is a portable zip with no installer, and that the app is deliberately built to run without administrator rights.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Matteo842/SaveState on GitHub
4. README
5. Releases