I have some old Flash games and animations that no longer work because Adobe Flash was discontinued. I’d like help using the Ruffle Flash emulator to preserve and run this content safely in modern web browsers.
Whether each SWF is self-contained matters, since many games load separate images, audio, XML files, or server data. Preserve the whole original folder structure, then test the SWF with Ruffle’s desktop app. For browser use, install the self-hosted Ruffle package beside your files and load its ruffle.js script from an HTML page. Run it through a local web server rather than opening the page with file://, which can break asset loading. Keep untouched backups, never reinstall Adobe Flash Player, and expect some ActionScript 3 or online multiplayer content to need fixes or remain incomplete.
Create a small test page for each SWF and keep the browser’s developer console open while it runs. A blank screen does not always mean Ruffle cannot handle the file. Missing fonts, blocked requests, filename capitalization, or an outdated hard-coded URL can produce the same result. The Network tab is especially useful for finding assets the game expects but you did not archive.
@omegaserver1491studi is right about keeping the folder structure, but I would preserve the working setup too. Once a game runs correctly, save that exact Ruffle build with the project instead of depending on a remotely hosted copy that may change. Record any settings or file edits you made, and keep the modified version separate from the untouched archive.
For content that relies on a dead website or login server, set realistic expectations. You may be able to preserve menus, artwork, and local gameplay while online features stay broken. Screenshots or a short screen recording of the original behavior can still be valuable when full emulation is not possible.
Don’t start by building a separate web page for every file. Use Ruffle’s desktop app to sort the collection first. It is faster for checking which SWFs run, which partly work, and which are obvious failures. Build browser wrappers only for the content worth keeping.
When you do move a project into a browser, serve the folder through a small localhost web server instead of double-clicking the HTML file. Modern browsers restrict file:// access, so a game may fail to load its own images, XML, audio, or other SWFs even though your archive is complete. The self-hosted Ruffle package expects its JavaScript and WebAssembly files to be served correctly too.
For unknown SWFs, I’d test them offline or in a separate browser profile. Old content may still try to contact advertising, tracking, or abandoned game servers. Keep Ruffle, the SWF, and every required asset together, but treat browser storage as temporary. If the game has saves, export or back them up separately rather than assuming they will survive a cache cleanup.
Do not throw away the original HTML page once you find the SWF. The page may contain settings the file needs, including FlashVars, its expected base path, dimensions, background color, and startup parameters. If you load only game.swf, Ruffle can appear broken even though the missing information was sitting in the old <object> or <embed> tag.
For each item, I would preserve it in this order:
- Save the original page source, SWF, and related folders without changing names.
- Record the original web address and any query string attached to the SWF.
- Copy values such as
flashvars,base, width, height,scale, andwmodeinto a small text file. - Make a second working copy for Ruffle tests.
- Recreate those settings in the Ruffle wrapper instead of assuming the defaults are correct.
FlashVars are especially easy to miss. A game might expect values like a level filename, language, user ID, or content directory before it starts. The same applies to relative paths. If the old page set a different base directory, moving the SWF beside your new HTML file may silently point all of its requests at the wrong place. @fusionninja’s suggestion to watch the Network tab will help, but preserving the page parameters first can save a lot of guessing.
Keep a short manifest with every preserved project. Note which Ruffle build you used, which SWF launches first, the intended player size, required parameters, known broken features, and whether networking is actually needed. For an unknown file, leave page scripting access disabled unless you confirm the content depends on it. That gives you something closer to a reproducible archive rather than a folder that happens to work on one computer today.
If the SWF was domain-locked, moving it to localhost may make it refuse to start even when every asset is present. Some files check their own URL, expect a particular hostname, or call JavaScript from the original page before showing anything. That can look exactly like a Ruffle compatibility failure.
Preserve the original URL and directory path in your manifest, as @silentgurux suggested, then check the browser console for security errors or failed ExternalInterface calls. For a dead site, you can reproduce the old hostname locally with a hosts-file entry and serve the archived folder under the same path. Keep that setup offline so you do not accidentally redirect a real, active domain or allow the content to contact old ad services.
Hard-coded http:// requests create another nuisance. If your wrapper uses HTTPS, the browser may block those requests as mixed content. Rehosting the expected files locally is usually cleaner than weakening browser security or changing the SWF.
Most importantly, treat any patched SWF as a convenience copy. Keep the untouched file and record a checksum for it. Ruffle can preserve access to the content, but the original SWF remains the archival object.
A plain AS2 banner animation and a full AS3 game with a preloader are barely the same preservation problem, and the thread is treating them like one job. The looping cartoon usually just runs in the desktop app, done, no wrapper needed. The AS3 game is where all the manifest and FlashVars advice from @silentgurux actually earns its keep. So sort by what you’re dealing with before sinking hours into text files for something that plays fine on a double click.
The point I’d underline is @fusionninja’s build-pinning. That’s the one people skip and regret. AS3 support in Ruffle is still moving, and a build that renders a game correctly today can quietly change behavior later, so the ‘working setup’ is part of the archive, not a detail. Zip the exact build with the project and write down the version. Everything else you can redo. That you can’t reconstruct once the old build is gone from your machine.
Ruffle preserves playback, not the project itself.
If you still have the original FLA files, scripts, fonts, audio, or artwork, archive those separately. An SWF is compiled output, and decompiling it later will not reliably restore the original timelines, names, or code structure.
Keep a clean copy of the SWF for Ruffle, but treat the editable source files as the real long-term preservation copy. That matters a lot if Ruffle exposes a bug you eventually need to fix rather than emulate around.