KahWee - Web Development, AI Tools & Tech Trends

Expert takes on AI tools like Claude and Sora, modern web development with React and Vite, and tech trends. By KahWee.

Why Browsers Killed Flash (And Why Designers Lost Out)

(Disclaimer: I work in the advertising industry which uses Flash for ads.)

Chrome made the announcement that coming December, Chrome 55 will disable Flash by default and you'll be prompted to enable Flash. This changes the game for a lot of advertising companies and publishing house that still rely on Flash to serve video.

Here's the blog post:

Flash and Chrome

Today, more than 90% of Flash on the web loads behind the scenes to support things like page analytics. This kind of Flash slows you down, and starting this September, Chrome 53 will begin to block it. HTML5 is much lighter and faster, and publishers are switching over to speed up page loading and save you more battery life. You’ll see an improvement in responsiveness and efficiency for many sites.

In December, Chrome 55 will make HTML5 the default experience, except for sites which only support Flash. For those, you’ll be prompted to enable Flash when you first visit the site. Aside from that, the only change you’ll notice is a safer and more power-efficient browsing experience.

Source: Chrome

Flash is primarily used for advertisements and games, hardly for analytics purposes as far as I know.

Mobile Killed Flash First

Before Chrome made this move, Apple already killed Flash on iOS back in 2010. Steve Jobs published "Thoughts on Flash"—a public letter explaining why Flash would never come to iPhone or iPad. His arguments: battery life, security, touch interfaces that don't work with hover states, and Adobe's closed ecosystem.

That was the real death blow. By 2016, mobile traffic had overtaken desktop. If your platform doesn't work on iOS, you're effectively locked out of half the mobile web. Chrome disabling Flash in 2016 was just finishing what Steve Jobs started six years earlier.

Why browser and device vendors hate Flash so much?

Battery consumption and ability to optimize

Flash exists in a time where it is the only consistent way to play videos across platforms and browsers. The downside to this is that this hinders browser innovation to make videos run smoother.

The real issue wasn't Adobe's effort level—Adobe did work on hardware acceleration for video in Flash. The problem was architectural: Flash Player was a plugin black box that browsers couldn't optimize or control.

When browsers control video through native APIs, they can:

Coordinate with device hardware: Use device-specific video decode chips (common in mobile SoCs) that are far more power-efficient than CPU decoding. Flash Player couldn't access these because the plugin sandbox prevented deep OS integration.

Manage power states: Pause or throttle video playback when tabs are backgrounded, adjust bitrate based on battery level, and coordinate with OS power management. Flash kept decoding in the background regardless of tab state.

Adapt to network conditions: Switch video quality dynamically based on cellular vs WiFi, signal strength, and data caps. Flash had its own network stack that couldn't see these mobile-specific conditions.

Handle thermal throttling: Mobile devices throttle CPU when they overheat. Browsers can reduce video quality or frame rate to prevent thermal issues. Flash Player had no visibility into thermal state.

This mattered most on mobile devices where battery life, thermal constraints, and variable network conditions are critical. A plugin architecture that worked fine on desktop PCs with unlimited power became a liability when phones became the dominant web platform.

The plugin sandbox that isolated Flash for security also prevented it from being optimized for mobile. Browsers needed to own the video pipeline to make it work on battery-constrained, thermally-limited, network-variable mobile devices.

The Adobe lockin and HTML5 video maturity

Using Adobe Flash meant you're locked in Adobe's ecosystem. Browsers prefer open standards built through collaboration—Flash was the opposite.

By 2016, HTML5 video had finally caught up to Flash's capabilities. The <video> tag gave browsers native video playback. Media Source Extensions (MSE) enabled adaptive streaming—the same quality switching that Flash video players did. Encrypted Media Extensions (EME) solved the DRM problem that kept Netflix on Flash for years.

One of the reasons Flash stuck for so long is Mozilla's insistence on not introducing DRM tools. Netflix needed DRM and wouldn't move to HTML5 without it. When Mozilla finally reversed the anti-DRM stance and implemented EME, the last major reason to keep Flash around disappeared.

With native browser APIs handling video, browsers could introduce features Flash never could: tab-based muting, picture-in-picture, background throttling, and integration with OS media controls. Flash Player couldn't do any of this because it was isolated in the plugin sandbox.

Security vulnerabilities

Flash had constant zero-day exploits that required emergency patches. I saw this firsthand—our ad ops teams dealt with clients panicking over Flash vulnerabilities that could compromise user systems through banner ads. For enterprise IT and security teams, Flash Player was a perpetual attack surface.

The problem is that Flash is a complex runtime with its own networking, rendering, and scripting engine. When a vulnerability showed up, it could bypass browser security sandboxes entirely. Browser vendors were stuck defending against attacks they couldn't control—every Flash vulnerability reflected poorly on the browser even though Adobe was responsible for patching.

Moving to native HTML5 meant browsers could control and harden the entire stack. No more waiting for Adobe to patch critical exploits.

Privacy issues

Flash implements its own set of cookies (Local Shared Objects) that browsers can't clear on user command. I've seen ad tracking companies take advantage of this—users would clear their browser cookies thinking they'd reset tracking, but Flash cookies persisted.

Browsers can't manage what they don't control. By 2016, browsers had added ways to clear Flash cookies, but the fundamental issue remained: plugin architecture meant giving up control over user privacy to Adobe.

Who loses as Flash disappears?

Advertisers are key users of Flash. Blocking Flash does remove a lot of advertisements for the end users. Browsers get happy users, web content publishers lost their ability to monetize.

The reason why advertisers couldn't switch easily is that designers couldn't figure out how to design advertisements in JavaScript productively. For example, a designer who is using Animate CC is still crippled by the lack of support for JavaScript export and scripting abilities within Animate CC.

The losers at this time are designers who lost their workflow for using Flash to design interactive advertisements. Some advertising companies are losing out too and are transiting inventory toward Flash. It's not going to be easy.

Adobe tried to adapt with Animate CC (formerly Flash Professional), but the transition to HTML5 was rocky. If you were working with Animate CC during this transition, I wrote about building custom HTML5 components for Animate CC that might help.