Silverlight China

A plain-English reference for the Silverlight era — and what to run instead

Which Browsers Still Support NPAPI Plugins?

The short answer

No mainstream, currently maintained browser supports NPAPI plugins. Chrome, Edge, Firefox, and Safari all removed the capability years ago, which is why plugins like Silverlight and Java cannot be installed into them no matter what a legacy website's "install the plugin" banner says.

If you're searching for an NPAPI-capable browser to reach one old application, the realistic options are old browser versions (with real downsides) or replacing the application — not a modern browser with a hidden setting.

What happened, browser by browser

  • Chrome. Google announced the final countdown for NPAPI in 2014, and the Chromium NPAPI deprecation guide documents the staged blocking that ended with full removal in September 2015. Since then, no Chrome version — and no flag, extension, or registry tweak — restores plugin support.
  • Firefox. Mozilla removed NPAPI support for plugins other than Flash in Firefox 52, released in March 2017. Silverlight, Java, and Acrobat plugins stopped loading from that version on; Flash's exception ended later as Flash itself was retired.
  • Edge. Microsoft's Chromium-based Edge inherited Chromium's plugin-free architecture, and even the original Edge never supported NPAPI. Edge's IE mode is a separate compatibility mechanism with its own rules — see does Edge's IE mode run Silverlight.
  • Safari and others. Apple likewise ended legacy plugin support in Safari, and Chromium-derived browsers (Brave, Opera, Vivaldi, and the rest) track Chromium, so they have no NPAPI either.

MDN's plugin glossary entry records the industry-wide arc: browser vendors coordinated a move away from plugins across the late 2010s, and by the early 2020s the model was gone from the mainstream web entirely.

What about niche or forked browsers?

A handful of small, independently maintained browser forks advertise continued support for legacy plugin interfaces. Treat these claims cautiously. Even where a fork can load an NPAPI plugin, you still need the plugin itself — and Silverlight is no longer supported or distributed by Microsoft — plus you inherit whatever security posture a small volunteer project can sustain against threats that major vendors dedicate large teams to. For anything involving logins or sensitive data, that is a poor trade. The same logic applies to old portable copies of mainstream browsers kept around specifically for one legacy app.

Why vendors were so unanimous

NPAPI dated to the mid-1990s and gave plugin code broad access to the machine, outside the browser's security sandbox. As browsers hardened everything else, plugins remained the soft spot — a major source of crashes, hangs, and security incidents, which is the story told in what NPAPI was and why browsers dropped it. Chrome's intermediate PPAPI approach, and why it didn't save Silverlight, is covered in NPAPI vs. PPAPI. The replacement was to build capabilities into the web platform itself — video, graphics, and eventually near-native compute via WebAssembly — so nothing needs to be installed at all.

What to do instead

If a site you rely on still demands an NPAPI plugin, the site is the problem to solve, not your browser. For a public site, look for the operator's modern replacement — most services that once used Silverlight moved to standard HTML5 delivery years ago. For an internal business app, the path runs through inventorying the app and choosing a migration target, and on locked-down or non-Windows hardware there was never a good option anyway — see can you run Silverlight on a Chromebook or Linux. Hunting for an NPAPI browser in the 2020s is treating the symptom; the plugin era is over, and it is not coming back.

Sources

← Silverlight China