Where Nestopia UE Stores Saves, States & Config — and How to Back Them Up

Sooner or later every long-term player asks the same questions: where are my saved games, where do save states live, and what do I need to copy before I move to a new computer or reinstall? Losing a battery save from a long role-playing game because a folder was tidied away is a rite of passage nobody needs to repeat. This guide explains where Nestopia UE keeps these files in general terms, how to find yours, and how to back them up sensibly.

The three kinds of data worth knowing about

• Battery saves — the in-game saves a cartridge would have kept on the cartridge itself, created when you save inside the game the way you would on real hardware. These are the files players usually care about most, because they represent whole playthroughs.
• Save states — snapshots of the game at an exact moment, made and loaded through the emulator rather than through the game’s own menus. States are convenient, but they are tied closely to the emulator and the game they were made with.
• Configuration — your settings: input mappings, video choices, folders the emulator remembers, and similar preferences, along with supporting data the emulator keeps for itself. Losing configuration is annoying rather than tragic, but re-creating controller mappings and settings takes time.

Where they live, in honest general terms

Nestopia UE is distributed in different forms — a portable Windows zip, the 2.0.0 Windows x86_64 build, a macOS .dmg and a Linux .deb, plus the legacy win32 builds — and where files are kept depends on the form you use and on your operating system. Portable-style builds generally keep their data in or near the emulator’s own folders, so the whole installation travels together. Installed builds on modern systems may instead keep user data in your user profile, following the platform’s conventions, so that the program folder itself stays clean.

Because of that variation, this page is not going to print a single exact path and pretend it applies to everyone — a wrong path confidently stated is worse than an honest method for finding the right one. Use the method below instead:

1. Start the emulator, play a game briefly, make an in-game save if the game supports it and a save state as well, then close the emulator.
2. If you use a portable build, look first in the emulator’s folder and its subfolders for files that appeared or changed just now, named for the game you played. Sorting a folder by date modified makes new save data stand out immediately.
3. If nothing new appears there, check your user profile area — the personal folders your operating system keeps for your account, including its application-data locations — for a folder associated with the emulator, and sort by date modified in the same way.
4. Once you find where one save landed, you have found the pattern for all of them. Note the location somewhere safe before you need it in a hurry.

Backing up properly

A backup is only real if it is separate from the original. Copying saves into another folder on the same drive protects you from accidentally deleting the emulator folder, but not from the drive failing. A sound routine for an emulator library is simple:

• Copy the whole data location, not individual files. Back up the emulator folder (for a portable build) or the profile data folder you identified, together with your game files you dumped yourself and any palettes or other additions you use. A complete copy restores everything in one step, with no archaeology.
• Back up before you change anything. Before upgrading to a new build — for example moving from a legacy win32 build to 2.0.0 from our download page — before moving computers, and before tidying folders, take a copy first. Most save losses happen during well-intentioned clean-ups.
• Keep at least one copy somewhere else. An external drive, or a reputable cloud storage service, turns a local accident into an inconvenience instead of a loss. Long playthrough saves and a carefully dumped personal library are worth that small effort — this is the one part of emulation housekeeping where a little paranoia pays.
• Date your backups. A folder name with the date in it prevents the classic mistake of restoring an old backup over a newer one, or keeping the wrong copy because both look identical.
• Test the backup once. Copy it back to a spare location, point a fresh install at it as appropriate, and confirm a save loads. An untested backup is a hope, not a backup.

Save states need extra caution

Battery saves follow the conventions of the original cartridges and are the most durable record of your progress. Save states are snapshots of a running emulator: treat them as belonging to the build and version that made them. When you move to a new build, load your progress through the game’s own save system where you can, and do not be surprised if very old states behave oddly in a much newer version. The safe habit is simple: before any upgrade, save in-game as well as by state, and keep the pre-upgrade backup described above until you have confirmed everything works.

Moving to a new computer

1. Back up the data location from the old computer, along with your own game files.
2. Install a fresh, complete copy of Nestopia UE on the new computer from the download page — do not start by copying program files piecemeal.
3. Put your saves and states back in the corresponding location for the new installation, using the find-it method above if the layout differs between builds.
4. Open the emulator, confirm your in-game saves appear, and re-check controller mappings under Options → Input, following the controller setup guide if needed.
5. Only delete the old copy once the new one has proven it holds your saves.

If you cannot find your saves at all, do not delete or reinstall anything in a panic — overwriting is how recoverable situations become permanent. Work through the find-it method calmly, check both the emulator folders and your user profile, and search your drive for the game’s name. The FAQ covers the version and platform background that explains why two installations may keep their data in different places.