Inside RetroArch, “Snes9x” is a libretro core — and the important thing to understand is that it is not a reimplementation or a cut-down clone. The core is upstream Snes9x, the same emulator code as the standalone apps, packaged so that RetroArch can load it. That one fact explains everything else on this page: which features belong to Snes9x, which belong to the RetroArch frontend, and why the two sometimes get credit for each other’s work. For the head-to-head, see our standalone vs libretro core comparison; for all platforms, the platforms hub; for downloads, the download page.
Proof it is the real thing: it ships in the official release
You do not have to take the core’s pedigree on faith. The official Snes9x 1.63 release on GitHub ships libretro packages — libretro.zip and libretro-x64.zip — as two of its six assets, alongside the Windows, Mac and Linux builds. The libretro documentation likewise lists Snes9x as a core built from the upstream project. When RetroArch offers to download the “Snes9x” core through its core updater, you are getting that same upstream code in libretro packaging.
Core vs frontend: who does what
The libretro model splits the job in two. The core emulates the SNES: the CPU, graphics, audio and enhancement chips (SuperFX, SA-1, DSP series and the rest that Snes9x emulates in code). The frontend — RetroArch — provides everything around the emulation: the interface, video drivers and shaders, controller abstraction, and the platform features layered on top of any core it runs. Keeping that split in mind prevents the two most common confusions:
- Netplay in RetroArch is a frontend feature. RetroArch’s own netplay system works across cores, including this one — libretro’s documentation explicitly recommends the Snes9x core for netplay. Contrast that with standalone Snes9x’s built-in netplay, whose own readme carries a maintainer’s note that it “has not been maintained and tested in a long time, so it might be broken”. If online play matters to you, the RetroArch route is the maintained one.
- Rewind in RetroArch is also the frontend’s. RetroArch applies rewind to the core from outside. But do not overcorrect: standalone Snes9x has its own, separate rewind implementation (added in 1.54, hold the R key) — it is simply switched off by default, because its rewind buffer defaults to 0 until you set a size in the settings. Two different systems, same name.
Files, firmware and formats in the core
The core loads the standard Snes9x formats: .smc, .sfc, .swc, .fig, .bs and .st. Battery saves are .srm — compatible with every SNES emulator, which makes moving saves between the core and the standalone app painless — and cheats live in .cht files shared with higan/bsnes.
One topic that imports confusion from other emulators: normal SNES games need no BIOS or firmware file in Snes9x, core or standalone, because the enhancement chips are emulated in code. There are exactly two narrow exceptions, both optional add-on hardware: Sufami Turbo loading can use STBIOS.bin, and Satellaview/BS-X content uses BS-X.bin — in the libretro setup these go in RetroArch’s system folder, as the core documentation describes. If a setup guide tells you to hunt down DSP firmware dumps for Snes9x, it has confused Snes9x with bsnes/higan-style emulation; ignore it.
When the core is the right choice
Choose the RetroArch core when you want one library and one interface across many systems, when you want RetroArch’s netplay or its shader/run-ahead ecosystem, or when you are on a platform the standalone release does not cover — the core reaches places like game consoles and mobile frontends that mainline 1.63 does not ship for. Choose the standalone app when you want the emulator exactly as its own team presents it — its native menus, its own netplay and rewind systems, zero frontend between you and the settings. Our standalone vs libretro core comparison walks the trade-offs in full, and the native desktop builds are covered in our Mac and Linux guides. Either way, the code underneath is the same Snes9x — start from the download page and the platforms hub.
One core, everywhere RetroArch goes
The libretro packaging also explains how “Snes9x” appears on platforms the standalone project never targets. The upstream repository’s own build system produces the libretro core for a wide range of systems — including Android builds of the core. That is a RetroArch core for Android, not a standalone Android app (the standalone Android answer is a different product entirely, Snes9x EX+). The same logic is how the core reaches iOS frontends and games consoles: the core travels with the frontend, which is precisely the reach the standalone releases — Windows, macOS, Linux — do not attempt.
Save handling follows the same split. Your in-game battery saves are the core’s standard .srm files, portable to the standalone app and other emulators. Save states, by contrast, are managed by the frontend: RetroArch snapshots the core’s state through the libretro interface, which is also the mechanism its rewind and run-ahead features build on. Practically, this means your .srm progress is yours to move anywhere, while frontend-level states belong to the setup that created them — a distinction worth understanding before you reorganise a library.