Why HTML5 Won the Browser-Game Format War

Flash dominated browser games from 2000 to 2015. By 2022 it was dead and HTML5 had taken over. The transition is now history but the reasons behind it shape how browser games are built today, and understanding them helps explain why the format works the way it does.

This piece walks through the technical and business factors that drove the shift, written from the perspective of someone (me, at Yowl Arcade, plus the engineering reviewers at this catalogue) who profiled both formats during the transition years.

Flash was a closed format

Flash was a proprietary technology owned by Adobe. Browsers ran it through a plugin that required users to install and update separately from the browser itself. Web standards bodies had no input on the format's direction; Adobe controlled it.

That closed structure had advantages during Flash's peak. Designers could rely on consistent behaviour across browsers because the runtime was identical everywhere. The toolchain (Flash Professional, ActionScript) was unified and well-documented. Designers could ship Flash content faster than they could ship equivalent HTML5 work.

The closed structure had disadvantages too. Security vulnerabilities accumulated faster than Adobe could patch them. Mobile browsers refused to install the plugin (most importantly Apple's iOS, which never supported Flash). Performance optimisations available in modern browsers were inaccessible because the plugin was a separate process.

By 2015 the disadvantages outweighed the advantages. Mobile browsing was overtaking desktop browsing, and Flash had no answer.

HTML5 was an open standard

HTML5 was developed by the W3C and WHATWG as an open standard that any browser could implement. The standard included Canvas (a 2D drawing surface), WebGL (3D graphics), Web Audio (audio scheduling), and a suite of related APIs that gave JavaScript everything it needed to build games.

The open-standard model had slow initial momentum. Different browsers implemented different parts of the standard at different times. The first few years of HTML5 game development were a compatibility nightmare; designers had to test extensively across browser-version combinations to find what worked.

That compatibility problem largely resolved by 2020. Modern Chrome, Firefox, Safari, and Edge all implement the HTML5 game APIs consistently enough that designers can target a single codebase. Mobile browsers caught up shortly after. The compatibility advantage that Flash held has reversed.

The mobile factor

Mobile browsing was the killing blow for Flash. Apple's decision to not support Flash on iOS in 2010 was framed at the time as a stance against a closed proprietary format. In practice it was a recognition that mobile devices needed a battery-friendly, security-vetted, sandboxed runtime, and Flash was none of those things.

Android followed Apple's lead within a few years, with mobile Flash support deprecated and then removed. By 2015 the mobile web had no Flash, and mobile browsing exceeded desktop browsing. Flash games could not reach the audience that mattered most for the future of the medium.

HTML5 ran natively on every mobile browser from launch. Designers who built HTML5 games could reach the full audience without porting work. The audience advantage compounded over time.

Performance crossed over

For years, Flash was faster than HTML5 for typical game scenes. The closed runtime was tuned for the kinds of operations games needed. HTML5 Canvas was slower because browsers had to do more work to translate generic JavaScript-and-Canvas calls into pixel updates.

Modern browser engines closed that gap by 2018 and surpassed it by 2020. The V8 JavaScript engine (Chrome), SpiderMonkey (Firefox), and JavaScriptCore (Safari) all received JIT optimisations and Canvas-acceleration improvements that made HTML5 performance competitive with native code for typical game workloads.

The catalogue at Yowl Arcade runs HTML5 games at 60fps on mid-range phones routinely. Tested on Osaka Osaka subway commutes, the performance is reliable enough that we can review games for design choices rather than for performance problems. That was not true five years ago.

The toolchain caught up too

The other thing Flash had going for it was the toolchain. Flash Professional was a unified design environment that handled art, animation, and code in one package. HTML5 game development required juggling multiple tools (art in Photoshop or Aseprite, code in a text editor, build pipeline in Webpack or similar).

That toolchain gap has narrowed. Modern HTML5 game frameworks (Phaser, PixiJS, Babylon.js) offer integrated development experiences that approach Flash's old workflow. Browser-based art tools eliminate the file-shuffling friction. The HTML5 toolchain is now competitive with what Flash offered at its peak.

What this means today

HTML5 winning the format war is now old news. The interesting question is what comes next. WebGPU is emerging as a successor to WebGL, with lower-level access to GPU compute that will enable a new generation of browser games. WebAssembly is bringing C++ and Rust game engines to the browser, with performance comparable to native.

The next format shift will not look like the Flash-to-HTML5 transition. HTML5 is the foundation; new technologies (WebGPU, WebAssembly, Web Audio improvements) are layers on top rather than replacements. The format is durable in a way that Flash never was.

For players, the practical effect is that the games on this catalogue will keep getting better. The technology is no longer the limiting factor. Design is.