# Ruffle: a Rust Flash Player emulator for desktop and the browser

> Ruffle reimplements Adobe Flash Player in Rust and targets both native desktop and the web through WebAssembly. Its ActionScript 3 support is usable but the README still calls the project unfinished, so adoption depends on which SWFs you actually need to run.

**ruffle-rs/ruffle** — A Flash Player emulator written in Rust

- Repository: https://github.com/ruffle-rs/ruffle
- Website: https://ruffle.rs
- Stars: 18,597 · Forks: 1,121
- Language: Rust
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/ruffle-rs-ruffle

## What Ruffle replaces, and who still needs it

Adobe Flash Player stopped shipping, but the SWF files did not disappear. Educational modules, old browser games, internal training animations and archived advertisements still sit on disks and web servers, and a plain browser will not open them. Ruffle is an emulator for that format, written in Rust, that runs the content without the original plugin. The README describes it as "an Adobe Flash Player emulator written in the Rust programming language" and states that it targets both the desktop and the web using WebAssembly.

The people who get value from this are not game studios. They are archivists, webmasters keeping a legacy page alive, teachers with interactive courseware, and developers who need to inspect a SWF file programmatically. Ruffle also ships a browser extension for Firefox and Chrome, which matters because it means the same emulator can be dropped into a page that still embeds Flash content, without asking visitors to install anything. The desktop build is the other main entry point, and it is the one you want if the files live on your own machine.

## How the emulator is put together

The workspace layout is the clearest description of the architecture. Cargo.toml lists members including core, swf, desktop, web, render, video, flv, wstr, scanner and exporter. The swf crate holds the SWF and ActionScript parser. The core crate holds the emulator itself and common code. Rendering is split out into render, with separate backends for canvas, WebGL, wgpu and a Naga-based ActionScript GPU abstraction layer under render/naga-agal. Video decoding lives in video with software and external backends, and flv handles Flash Video.

That separation is deliberate and it explains the platform story. The desktop client uses wgpu-rs, while the web client and browser extension use wasm-bindgen. Both drive the same core, so a bug fixed in the interpreter benefits the extension and the desktop app at once. The wstr crate is worth noting: it is a Flash-compatible string implementation, which hints at how much of this project is about matching the original runtime's quirks rather than writing a clean new interpreter. There is also a build_playerglobal step under core that compiles the builtin Flash classes for ActionScript 3, and it needs Java on your PATH.

## Installing Ruffle and running your first SWF

The fastest route is the web demo at ruffle.rs/demo, where you click "Select File" and load a SWF of your choice. For a local desktop install, the README points at nightly builds for desktop and web platforms, and the wiki page on using Ruffle covers the details. Building from source needs the latest stable Rust toolchain plus Java available as java.

On Ubuntu or Debian the README gives this dependency line, which pulls in the audio, device, font and TLS libraries the desktop client links against:

```bash
sudo apt install pkg-config libasound2-dev libudev-dev libfontconfig-dev libfreetype6-dev libssl-dev default-jre-headless g++
```

Fedora and RHEL users get an equivalent set of packages:

```bash
sudo dnf install pkgconf-pkg-config alsa-lib-devel systemd-devel fontconfig-devel freetype-devel openssl-devel java-latest-openjdk-headless gcc-c++
```

With those in place, the build and run command is a single cargo invocation. Omitting --release gives you a debug build:

```bash
cargo run --release --package=ruffle_desktop
```

To open a specific file, pass its path as an argument. This is the first real use, and you should see the Ruffle window open and begin playing the animation or game:

```bash
cargo run --release --package=ruffle_desktop -- test.swf
```

On macOS the README offers a Homebrew tap instead, with a caveat worth reading twice: it is HEAD-only, so updates require a separate fetch command rather than a normal upgrade.

```bash
brew install --HEAD ruffle-rs/ruffle/ruffle
```

## The scanner and exporter, for collections rather than single files

Two workspace members exist for bulk work, and they are the parts most likely to be overlooked. The scanner takes a folder of SWFs and an output filename, attempts to read every Flash file it finds, and reports on the success of that parsing. That is a coverage measurement tool, not a player. If you maintain an archive and want to know what proportion of it Ruffle can even open, this is the command the README documents:

```bash
cargo run --release --package=ruffle_scanner -- scan folder/with/swfs/ results.csv
```

The exporter renders a SWF to a PNG screenshot. The README states that it currently requires hardware acceleration but can run headless, with no window. It accepts an output directory and a frame count:

```bash
cargo run --release --package=exporter -- path/to/file.swf path/to/screenshots --frames 5
```

That hardware acceleration requirement is a real constraint in CI or on a headless server, and the README does not document a software fallback for the exporter. If your pipeline runs on machines without a GPU, plan for that before you build tooling around it.

## Where Ruffle falls short

The project status section is unusually direct. It says Ruffle supports ActionScript 1, 2 and 3 "pretty well, but it's still not finished by any means," and directs users to the issue tracker. Treat that as the headline limitation: this is an emulator that aims for compatibility with a large, undocumented runtime, and compatibility work of that kind is never complete. A SWF that leans on an unimplemented ActionScript 3 API will not fail gracefully in a way you can predict from the README; the README does not document a compatibility matrix or a list of known-missing features.

The release cadence reinforces the point. The repository publishes nightly builds, with releases dated 2026-09-19, 2026-09-20 and 2026-09-21. Nightly tags mean there is no stable versioning contract to pin against, and the workspace version in Cargo.toml is 0.6.0, which is pre-1.0. If your requirement is a frozen, tested runtime with a support agreement, Ruffle is the wrong tool. It is also the wrong tool if you need to author or compile Flash content rather than play it; nothing in the README describes a compiler. And if your content is video-heavy, note that video decoding is delegated to separate backends, so what works depends on the platform build you have.

## Ruffle against the Flashpoint and Ruffle-alternative approach

The obvious comparison is with preservation projects that keep the original Flash plugin alive inside a bundled, sandboxed browser, rather than reimplementing the runtime. Flashpoint is the best-known example of that approach. The difference in method is the whole argument. Flashpoint ships the actual Adobe plugin and a launcher that feeds it content, which means compatibility is as good as the original plugin's, but you are distributing and running proprietary, unmaintained binaries with the security history that comes with them.

Ruffle takes the opposite path. It is a reimplementation, so there is no Adobe code in the loop, and the README states it targets the web through WebAssembly, which is what makes a browser extension possible at all. The cost is that every ActionScript behaviour has to be rediscovered and rewritten, which is exactly why the project status page is hedged. If your priority is running a difficult SWF today, the plugin-preservation route will get further. If your priority is a maintainable, source-available runtime you can embed in a page or ship in a desktop app, Ruffle is the only one of the two that fits.

## Licence, upgrades and what a nightly cadence costs you

The GitHub licence field reports NOASSERTION, but Cargo.toml is explicit: the workspace package declares license = "MIT OR Apache-2.0". Dual licensing under those two terms is permissive and standard for Rust projects, and it means you can choose either. The repository also contains a LICENSE.md at the top level, so read that file rather than the GitHub badge if the distinction matters to your organisation. This is a description of what the files say, not legal advice; if you are redistributing Ruffle inside a product, have someone qualified read the actual licence text.

Upgrade cost is the other practical consideration. Nightly builds appear daily, and there is no stable channel documented in the README. The macOS Homebrew install is HEAD-only and needs brew upgrade --fetch-HEAD ruffle to move forward, which the README calls out as a note. Building from source means tracking the master branch and re-resolving a large dependency tree that includes wgpu, egui, naga and gc-arena. For a desktop user this is a background chore. For anyone shipping Ruffle inside another product, it means you own the compatibility testing yourself, because a nightly tag tells you the date but not what changed.

## Conclusion

Adopt Ruffle if you need to keep a collection of SWF content playable and you can accept the README's own caveat that the emulator is not finished. Do not adopt it if your content depends on ActionScript 3 features that Ruffle has not implemented, or if you need a support contract, since this is a community project with nightly builds rather than a vendor release. Before committing, run your own SWFs through the exporter or the web demo and check the licence files in the repository, because the GitHub licence field reports NOASSERTION while Cargo.toml declares MIT OR Apache-2.0.

## FAQ

### How do I use the Ruffle Flash emulator?

The README points to the web demo at ruffle.rs/demo, where you click "Select File" and load a SWF. For a local install, nightly builds are published for desktop and web, and the wiki page on using Ruffle covers the details.

### How do I install Ruffle on Linux?

Build from source with the latest stable Rust toolchain and Java on your PATH, after installing the Linux dependencies the README lists for your distribution, such as pkg-config, libasound2-dev and libudev-dev on Ubuntu or Debian. Then run cargo run --release --package=ruffle_desktop.

### How do I install the Ruffle Chrome extension?

The README links a Chrome Web Store listing for the Ruffle Flash emulator extension. The web and extension builds are produced from the web directory, and the README refers to web/README.md for building either one from source.

### How do I install Ruffle on Android?

The Android application lives in a separate repository, ruffle-android, and the README directs you to the building-from-source instructions in that project's CONTRIBUTING.md rather than the main repository.

### How do I install Ruffle on Windows?

The README does not give Windows-specific build steps. It points to nightly builds of Ruffle for desktop and web platforms, and to the wiki page on using Ruffle for more detailed instructions.

## Sources

- [Issues](https://github.com/ruffle-rs/ruffle/issues)
- [Project website](https://ruffle.rs)
- [README](https://github.com/ruffle-rs/ruffle/blob/master/README.md)
- [Releases](https://github.com/ruffle-rs/ruffle/releases)
- [ruffle-rs/ruffle on GitHub](https://github.com/ruffle-rs/ruffle)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ruffle-rs-ruffle