Here is the confusion this page exists to clear up: "Snes9x" names both a set of standalone applications and a libretro core — the same upstream emulation code packaged to run inside RetroArch and other libretro frontends. The project’s 1.63 release literally ships both side by side: Windows, Mac and Linux app builds, plus libretro.zip and libretro-x64.zip core packages. So the question is never which one emulates "better" in the abstract. It is which shell you want around the same core, and which layer — app or frontend — you want owning your features. More context is in our comparisons hub and our download page.
What is actually the same
The SNES emulation itself comes from the one Snes9x codebase in both cases. The games, the enhancement-chip handling, the broad compatibility — including its known limits, such as the unemulated DSP-3 and Seta-11/18 titles named in the readme — do not change because the window around them changed. Both forms read the same ROM formats (.smc, .sfc, .swc, .fig, .bs, .st, and single-ROM .zip, .gz or .jma archives), both use .srm files for battery saves — a format the readme notes is compatible with all SNES emulators — and both work with .cht cheat files. Your library and your in-game saves are portable between the two; it is everything around the game that differs.
What the standalone apps give you
The standalone route gives you Snes9x as its authors present it: a menu-driven Windows program (with native Mac and Linux counterparts), its own settings dialogs, its own hotkeys, and its own feature implementations. Save states are Snes9x’s own system — 10 quick slots per bank across 10 banks, files .000–.099, written with your .srm saves to a Saves folder beside the executable. Rewind is Snes9x’s own implementation too, present since 1.54 on the R key — but remember it is disabled until you set a non-zero rewind buffer, because the default buffer size is 0. Shaders are built in and capable: Cg under Direct3D and OpenGL, GLSL under OpenGL, and slang under OpenGL and Vulkan. Netplay exists in standalone form — up to five players over TCP port 6096 — but carries the project’s own warning that it has not been maintained in a long time and might be broken.
In short: in the standalone apps, what you see is what Snes9x itself does. When a guide shows a Snes9x menu, it is showing you this program, and troubleshooting has exactly one layer to consider.
What changes inside RetroArch
Load the same code as a libretro core and the frontend takes over the surrounding jobs. RetroArch owns the video and audio settings, the controller profiles, the library, the screenshots — and the headline features. Rewind becomes a RetroArch feature applied to the core (the libretro documentation lists rewind as supported for the Snes9x core, provided by the frontend), netplay becomes RetroArch’s maintained netplay — the libretro docs describe the Snes9x core as recommended for netplay for exactly this reason — and shaders come from RetroArch’s own preset system rather than Snes9x’s dialogs. Run-ahead, achievements and other frontend-level systems, where you use them, are likewise RetroArch’s contribution, not the core’s.
That division of labour is the whole point, and also the whole learning curve. Settings that standalone users find in Snes9x’s menus are now split between RetroArch’s menus and the core’s own options list, and your saves and states live in RetroArch’s folder structure instead of beside an executable. In exchange, every other core you run behaves the same way — which is why our broader Snes9x vs RetroArch comparison frames this as a lifestyle choice, not a quality ranking. The Platforms cluster covers the same ground from the installation side in the Snes9x RetroArch core guide linked from our platforms hub.
Who should pick which
- Pick the standalone apps if SNES is your only system, you want the official Snes9x interface and documentation to match your screen exactly, or you are on a modest PC and want the lightest possible setup — the readme’s recommendation is only a 1 GHz-class CPU.
- Pick the libretro core if you already live in RetroArch, you want its netplay or frontend features such as run-ahead, or you want one consistent setup across many consoles and devices — the core is also how Snes9x reaches platforms with no standalone app.
- Switch freely: keep your ROMs and
.srmsaves somewhere both can reach, treat save states as per-build and disposable, and you can change your mind at any time without losing real progress.
Verdict
Same heart, different shell. The standalone apps are Snes9x unmediated — simpler, self-contained, and the reference experience. The libretro core is Snes9x as a citizen of a larger frontend — more powerful for multi-system and online players, at the cost of learning RetroArch’s layer as well. Neither is the "real" Snes9x; the 1.63 release ships both because both audiences are real. See also Snes9x vs RetroArch and the best SNES emulator field guide.
Where the core travels that the apps do not
One last asymmetry is worth knowing. The standalone apps cover the desktop — Windows, macOS and Linux — and stop there. The libretro core travels further: because frontends exist for so many systems, the Snes9x core is how Snes9x emulation reaches places the mainline project ships nothing for, including Android phones (through RetroArch; the project’s own build system also compiles the libretro core for Android) and a long tail of handhelds, single-board computers and console homebrew frontends. That reach is a real argument for learning the core’s way of doing things if your playing is spread across gadgets. It does not make the standalone apps redundant — on a desktop they remain the simpler, reference experience — but it does mean the core is the more future-flexible of the two shells, and the one most new devices will meet first.