Google Swiffy and the Automated Tools That Tried to Convert Flash Games to HTML5
Rewriting a game by hand from ActionScript to JavaScript was slow and expensive, so Google built a tool that tried to do it automatically. It worked, right up until a game did anything Swiffy couldn't translate.
Swiffy was a free conversion tool from Google that took a compiled .swf file and produced an equivalent HTML5 bundle: a JavaScript runtime paired with a JSON description of the original file's vector shapes, timeline, and simple ActionScript logic, designed to render visually identically inside a browser with no Flash Player involved at all. For banner ads, animated logos, and simple interactive graphics, it worked remarkably well, and that was exactly its intended audience — Swiffy launched primarily as an answer to the advertising industry's problem of Flash-based ad creatives no longer running on an increasing share of mobile devices, which never shipped Flash Player in the first place.
Where it actually succeeded
The tool handled Flash's vector drawing model well, since translating shapes, gradients, and basic timeline animation into an HTML5 canvas or SVG equivalent is a relatively contained problem with a clear one-to-one mapping. Simple tweened animations, basic button interactions, and straightforward ActionScript 2 logic converted cleanly enough that Swiffy saw real adoption for exactly the use case it targeted: short animated ad units that needed to keep working as mobile ad inventory grew and Flash-based creative increasingly couldn't be served to it at all.
Why full games were a different problem entirely
Games broke the model quickly. Swiffy's automatic conversion supported only a subset of ActionScript, and it explicitly could not handle the more complex ActionScript 3 features that most substantial Flash games actually relied on: custom class hierarchies, certain display list manipulations, and calls to specific runtime APIs that had no clean HTML5 equivalent. A simple animated banner rarely touches any of that. A real game — with save states, physics, dynamic asset loading, and often years of accumulated code from a team that never expected anyone to need to convert it automatically — touches almost all of it. Studios that tried running an existing game through Swiffy generally got back something that loaded, displayed the first frame correctly, and then failed somewhere in the actual gameplay logic, which made the tool far more useful as a proof of concept than as a production pipeline for anything beyond the simplest browser toys.
This gap is a big part of why the transition covered in the broader explanation of what changed technically after Flash died ended up being a manual rewrite process for most serious titles rather than an automated one. Studios that wanted to keep a specific game alive past Flash's decline typically had two real choices: rebuild it by hand in a JavaScript framework, often reusing only the original art and audio assets rather than any code, or rely on Adobe's own successor tooling, since Adobe Animate's HTML5 Canvas export path became the more commonly used route for teams that wanted an authoring workflow similar to the one they already knew, paired with libraries like CreateJS to handle the runtime side that Swiffy had tried to solve more narrowly for ad creative alone.
The advertising industry's bigger role in all this
It's worth remembering that Swiffy existed mostly because of Google's own commercial interest in keeping display advertising functional as the device landscape shifted under it. Ad exchanges and publishers needed creative assets that would render everywhere a bid could win an impression, and a Flash banner that silently failed to render on a growing share of phones and tablets was a direct revenue problem for everyone in that chain, not an abstract compatibility concern. That pressure is why the tool got real engineering investment and a genuinely polished conversion pipeline for its narrow use case, while nobody funded an equivalent effort aimed specifically at converting full games, since no single company had the same direct financial exposure to broken game files the way ad networks did to broken ad creative. The industry eventually moved toward HTML5-native creative standards enforced by ad exchanges themselves, which made purpose-built converters like Swiffy less necessary over time regardless of how well the tool worked.
What happened to it
Google eventually discontinued Swiffy as part of a broader wind-down of several Google Labs-era side projects, well after HTML5 Canvas and WebGL-based game engines had matured enough that most serious studios weren't relying on automatic .swf conversion for anything beyond quick, disposable ad units anyway. Existing converted output kept working since Swiffy's runtime library was just JavaScript and could still be self-hosted by anyone who'd already generated it, but no new conversions could be produced through Google's own service once it shut down, which pushed the small number of remaining users toward either a manual rewrite or one of the newer open-source SWF tools that had picked up where it left off. It's a minor footnote next to the bigger preservation and emulation tools this site covers elsewhere, but it's a useful one: Swiffy is a clear, documented example of exactly where the line sat between what could be automated away and what genuinely needed a human developer to rebuild by hand, at a moment when a lot of companies were hoping the answer would be "all of it."