Why Java Applets Died (And What Replaced Them)

high rise buildings during night time

Java applets were the original way to put real, executable software inside a web browser. From 1995 to roughly 2015 they powered everything from RuneScape to interactive math demos to bank-statement viewers. Then they died, and they died for specific reasons: browsers dropped the plugin architecture they required, Oracle deprecated them in Java 9 (2017), and a decade of security vulnerabilities made them untenable. Here’s the full story of why Java applets died and what came after.

Key takeaways

  • Java applets ran via the Java Plug-in inside browsers through the NPAPI plugin architecture from 1995 onward.
  • Chrome dropped NPAPI support in 2015, killing applets in the dominant browser; other browsers followed.
  • Oracle deprecated the Java Plug-in in Java 9 (September 2017) and removed it entirely in Java 11 (2018).
  • Persistent security vulnerabilities made Java applets a major attack vector through the 2010s — a contributing cause, not a cosmetic one.
  • JavaScript, HTML5, WebAssembly, and Java Web Start replaced different parts of what applets used to do.

What Java applets were

A Java applet was a small Java program embedded in a web page via an HTML tag. The browser, via the Java Plug-in, downloaded the applet’s bytecode (a .class or .jar file), verified it against the Java security sandbox, and executed it inside the browser window. The applet ran as actual Java — with full access to Java’s standard library, threading, networking, and graphics — but inside the browser’s sandboxed environment.

This was a remarkable capability when Sun introduced it with Java 1.0 in 1995. Browsers in 1995 could barely render images consistently. Embedding a real, cross-platform programming runtime that could draw, play sound, do math, and connect to servers — that was magic. Java applets were the proof-of-concept for “the web as application platform” decades before the term became common.

The 1995-2005 boom

The first decade of Java applets was the platform’s golden era. Interactive math and physics simulations on educational sites. Multiplayer chess and checkers on game portals. Stock-quote tickers on financial news sites. Online banking interfaces. Early webmail clients. The Java Plug-in shipped with every Java install, and Java was preinstalled on most Windows computers, so penetration was effectively universal.

For games, the most famous applet of all was RuneScape, which launched in 2001 as a Java applet running in a browser tab. For most of its first 15 years, RuneScape was a Java applet, and tens of millions of players got their MMO fix through that one-tab browser interface. Other major applet games included Yahoo Games’ chess/checkers/cards suite, various dungeon-crawl applets, and a long tail of educational and puzzle games.

The cracks (2005-2012)

Three trends weakened the applet model through the late 2000s:

JavaScript got good. The 2005 release of Ajax (XMLHttpRequest used asynchronously) and the 2008 release of V8 (Chrome’s JavaScript engine) made JavaScript fast enough to do real work. Web apps could be built in JavaScript that previously required applets. The “Java for interactivity, JavaScript for sprinkles” division of labor inverted.

Flash dominated games. For browser games specifically, Flash was lighter, easier to author, and had a more polished plugin. New game developers chose Flash; the Java applet game scene stagnated.

The browser plugin model itself came under pressure. Plugins were a security liability and a performance drag. Browsers started looking for ways out of the plugin architecture.

The security disaster (2012-2014)

Through 2012 and 2013, a series of major Java security vulnerabilities — including CVE-2012-4681 and CVE-2013-0422 — let attackers escape the Java sandbox via Java applets and run arbitrary code on victims’ machines. The Department of Homeland Security publicly recommended disabling Java in browsers in January 2013. Apple removed the Java Plug-in from OS X by default. Mozilla added Java to its blocklist for vulnerable versions.

The vulnerabilities kept coming. Oracle’s Java patch cycle could not keep up with the attack surface. By 2014, the consensus in the security community was that having the Java Plug-in installed in a browser was a serious risk regardless of which sites you visited, because malicious ads on legitimate sites were exploiting the plugin.

This was a major contributing cause to Java applets’ death. The technology had become not just unfashionable but actively dangerous, and the engineering organization at Oracle could not get ahead of the security debt.

NPAPI removal: the kill switch

The killing blow came from the browsers themselves. Java applets ran via NPAPI (Netscape Plug-in API), the plugin architecture browsers had inherited from Netscape Navigator in the 1990s. NPAPI was old, complex, and a major source of browser crashes and security issues.

Chrome announced its NPAPI deprecation in 2013 and completed removal in September 2015 (Chrome 45). With Chrome being the dominant browser, the removal effectively killed Java applets for most users overnight. Firefox followed with a similar timeline. Safari had already restricted plugins heavily. Internet Explorer kept NPAPI longer but its market share was declining rapidly. Edge (Microsoft’s Chrome-based successor) never supported NPAPI.

By the end of 2017, no major browser supported the Java Plug-in by default. Applets could still technically run in a few legacy configurations (Internet Explorer 11 on Windows with the right Java version), but the ecosystem was dead.

Oracle’s deprecation and removal

Oracle followed the browsers. In Java 9 (September 2017), Oracle deprecated the Java Plug-in officially. In Java 11 (September 2018), Oracle removed the Plug-in entirely, including the Java Web Browser Plugin and JNLP-related browser code. Java applets ceased to be a supported Java feature.

The Wikipedia article on Java applets documents the timeline precisely, including the specific Java versions involved and the platform-level removals.

What replaced applets

Different parts of the applet-using market migrated to different replacements:

Games and interactive content moved to HTML5 and JavaScript. Phaser, Three.js, PixiJS, and the broader HTML5 game development stack handle most of what applets used to do for games. RuneScape specifically migrated away from the applet to NXT (its native Windows/Mac/Linux client) and eventually killed the in-browser applet entirely.

Performance-sensitive code moved to WebAssembly. WebAssembly (spec 2017) lets compiled languages — Rust, C++, Go, AssemblyScript — run in browsers at near-native speed. For the applet use cases that needed real performance, WebAssembly is the actual successor.

Educational simulations migrated to JavaScript libraries or HTML5 canvas implementations. The physics demos and math interactives that used to run as applets now run as JavaScript with Canvas or WebGL.

Banking and enterprise applets migrated to web apps or native installers. The “trusted code from a verified source running in the browser” use case is now handled by signed web applications (which work via TLS certificates and the browser’s general security model) or by native installers via Java Web Start (though Web Start itself was deprecated in Java 11).

What was lost

The Java applet ecosystem produced thousands of small interactive programs that are now functionally inaccessible. Educational sites with applet-based math demos have broken pages. Old game portals with Java game embeds show empty boxes. RuneScape’s pre-2017 player experience can’t be reproduced exactly because the applet client doesn’t run anywhere.

There’s no Ruffle equivalent for Java applets — no widely-adopted open-source emulator that runs old applets in modern browsers. The CheerpJ project (by Leaning Technologies) is a notable attempt: a WebAssembly-based JVM that can run Java applets in browser. It works for many cases but isn’t comprehensive. Most legacy applets remain unreachable.

For the parallel browser-plugin-death story for Adobe’s products, our death of Adobe Shockwave piece covers the analogous shutdown of Macromedia/Adobe’s contribution to the plugin era.

Why the death was inevitable

Java applets died because three independent forces converged: the security model was fundamentally broken in ways that couldn’t be patched fast enough; the browser plugin architecture was being phased out for excellent reasons; and the replacement technologies (JavaScript engines, HTML5, eventually WebAssembly) caught up and surpassed what applets offered.

No single cause killed them. If only one of those forces had been present, applets might have survived in some form. All three together made the death inescapable. By 2015 even Sun/Oracle’s strongest defenders inside the Java community accepted that applets were finished. The only argument was about timing.

The legacy

Java applets proved that browsers could host real applications. They were the first browser runtime that let you build something substantive without the page reloading. Everything from Google Maps to modern single-page web apps traces its conceptual ancestry to “what if we could have a real program inside a web page” — a question applets answered first.

The model was wrong (plugins, sandboxed binary runtimes, separate security models from the browser) but the ambition was right. JavaScript, HTML5, WebGL, and WebAssembly all exist in part because applets demonstrated that the browser could be more than a document viewer. Applets are dead; their idea is everywhere.

For a browser game that demonstrates what the post-applet web can do without any of the plugin overhead, the Chrome Dino game at the top of this site is the minimal-viable proof: HTML5, JavaScript, no plugins, runs everywhere.

Frequently asked questions

When did Java applets die?

The death was gradual: Chrome dropped NPAPI in September 2015, killing applets in the dominant browser. Oracle deprecated the Java Plug-in in Java 9 (September 2017) and removed it entirely in Java 11 (September 2018). After 2018, applets were unsupported in any modern Java version or major browser.

Why did Chrome remove Java applet support?

Chrome removed NPAPI plugin support entirely in 2015 for security and stability reasons. The plugin model was a major source of browser crashes and a persistent attack surface. Java applets were collateral damage from a broader architectural decision.

Can I still run Java applets today?

Not in any default modern browser configuration. The CheerpJ project provides a WebAssembly-based JVM that can run some applets in browser. Some specific enterprise configurations using older browsers still work. The general case is dead.

What replaced Java applets?

JavaScript and HTML5 for general interactivity, WebAssembly for performance-critical code, and native installers for the enterprise use cases that previously used applets and Java Web Start.

Was RuneScape a Java applet?

Yes, for most of its first 15 years. RuneScape launched in 2001 as a Java applet and ran that way through the mid-2010s. Jagex migrated to the NXT native client and eventually killed the applet entirely as browser support for Java disappeared.

The bottom line

Java applets died because the browser plugin architecture they required got phased out, Java’s security model couldn’t keep up with attackers, and JavaScript caught up to what applets uniquely offered. By 2018 the technology was officially dead. The use cases survived in JavaScript, HTML5, and WebAssembly. The plugin model is over; the web-as-application-platform vision applets pioneered is more alive than ever.

🔌 Connect any AI assistant to dinogame.gg — we run an MCP server: https://dinogame.gg/mcp