05 Emulation
Ruffle
An open-source reimplementation of the runtime, written to run inside the browser that removed the original.

Rebuilding a player from its file format, one instruction at a time, in public.
oujouer.com collection
A runtime rebuilt from the inside
Flash died twice. The first death was commercial and gradual: Adobe announced in 2017 that it would end support for Flash Player, giving the industry three years to migrate. The second death was surgical: browsers began actively blocking the plugin rather than simply leaving it unsupported, so that even someone who wanted to run the old runtime on an old machine found the browser itself standing in the way. Those two deaths together destroyed access to roughly two decades of browser-based work — games, animations, interactive art, educational tools — without a clean migration path for most of it. Ruffle is the attempt to undo that damage from inside the browser that caused it.
The project is an open-source reimplementation of the Flash Player runtime, written in Rust and compiled to WebAssembly so that it runs natively in any modern browser without a plugin. That inversion is the whole point: the environment that blocked the original runtime now hosts its replacement. Ruffle reads SWF files — the compiled binary format that Flash Player executed — and interprets them directly, handling the drawing model, the audio pipeline, the input events and the scripting engine. Nothing is translated or converted; the original file sits untouched, and Ruffle stands in for the runtime that is no longer there.
What the reimplementation actually had to reconstruct
SWF is not a simple format. It accumulated features across roughly two decades of development at FutureSplash, Macromedia and then Adobe, layering vector graphics, streaming audio, video codecs, a bitmap compositing model and two substantially different scripting languages on top of one another. ActionScript 1 and 2 were loosely typed, prototype-based languages; ActionScript 3, introduced with Flash Player 9 in 2006, was a compiled, strictly typed language that ran on a completely different virtual machine called the AVM2. Ruffle had to implement both virtual machines, and the gap between them is not cosmetic — the AVM2 is closer in character to the JVM than to the scripting engines that preceded it.
The vector graphics model presented its own complexity. Flash used a fill-rule and stroke model with specific edge-case behaviour that content authors relied on, sometimes accidentally — content that happened to depend on a rendering quirk would break if the reimplementation corrected it rather than reproducing it. This is the central tension in any clean-room reimplementation: accuracy requires reproducing bugs as well as features, and distinguishing a bug from an intended behaviour requires either the original specification or exhaustive testing against the original runtime. Ruffle uses both.

At this scale preservation is a storage problem before it is a software problem.
oujouer.com collection
Audio is handled through the Web Audio API, which modern browsers expose natively. Video — MP4 and FLV streams embedded in SWF files — required implementing or integrating decoders, since the same codec libraries that Flash Player shipped with no longer come bundled with browsers. The Ruffle project has addressed video support incrementally, and it remains among the more technically demanding areas of the implementation, partly because the container formats and codecs involved were proprietary when Flash was current.
The network and the organisations behind it
Ruffle is not the product of a single company or institution. It emerged from open-source contributors, gained formal support from the Internet Archive in San Francisco — which integrated it into the Archive's own Flash software collection — and has been closely associated with BlueMaxima's Flashpoint, the preservation project that assembled the largest known collection of browser games and the environments needed to run them. The Internet Archive's adoption was significant because it gave Ruffle a working deployment at scale, making tens of thousands of SWF files playable in-browser through the Archive's catalogue without any change to the files themselves.
The project is written in Rust, a choice that matters for reasons beyond fashion. Rust's memory-safety guarantees reduce the class of security vulnerabilities that plagued the original Flash Player throughout its lifetime — the CVE database for Adobe Flash Player runs to hundreds of entries, many of them involving memory corruption. A reimplementation that reproduced those vulnerabilities would be worse than useless for any institution serving it to the public. Rust does not eliminate bugs, but it eliminates an entire category of the worst ones, which is why the Ruffle project lists safety explicitly alongside compatibility as a design goal.

A public terminal is the real test: if the emulator loads in the page, the catalogue entry is playable.
oujouer.com collection
Deployment takes two forms. The standalone desktop application reads SWF files locally, useful for preservation work and for running content that calls out to servers that no longer exist — though in the latter case, the network calls will still fail, because Ruffle cannot reconstruct a defunct server any more than it can reconstruct deleted data. The browser build distributes as a JavaScript package that website operators — archives, libraries, portals — can drop into an existing page to replace the old plugin tag. This makes it unusually easy for a site that already hosts SWF files to restore playability without re-encoding or rehosting any content.
What it covers, and what it does not
ActionScript 2 content — the majority of the Flash games catalogue, since most were built before AS3 became the dominant language — is substantially supported. Complex AS3 content runs with varying fidelity, and some of it does not run at all. The project tracks compatibility through community testing: volunteers run SWF files, report what breaks and where, and open issues in the public repository. This is slow, manual work. The Flash catalogue is enormous, and the long tail of obscure content — regional portals, educational publishers, intranet tools — may never be fully tested.
There is also the deeper question of what breaks beneath the scripting layer. Some SWF files loaded assets at runtime from URLs that no longer exist; Ruffle can execute the loader call but cannot supply the missing resource. Some content depended on shared objects — Flash's local storage mechanism — storing data that is now gone. Some depended on server-side logic for multiplayer, scoring or licence verification. Ruffle restores the runtime; it does not restore the infrastructure the runtime once connected to.
Ruffle is the attempt to undo that damage from inside the browser that caused it.
This is not a criticism of the project — it is a statement about the nature of the preservation problem. A runtime emulator is a necessary condition for playability, not a sufficient one, and the Software Preservation Network and its institutional partners have spent considerable effort documenting how much of what appears preserved is in fact only partially functional. Ruffle is the best available answer to the runtime problem. The infrastructure problem is a separate, harder question.
What Ruffle demonstrates is that the plugin-era web is not necessarily gone beyond recovery. The browser that removed Flash can host a faithful enough reimplementation of it that the majority of the catalogue — the games, the cartoons, the interactive toys that accumulated across two decades on portals from Newgrounds to Miniclip — is again reachable without any special hardware, any legacy operating system, or any browser that predates the block. That is not nothing. In terms of public access to a cultural archive that was briefly treated as disposable, it is quite a lot.

Stack the layers and the decision makes itself — preserve the reader and everything it reads returns.
oujouer.com collection