NPAPI vs. PPAPI: What's the Difference?

Two plugin APIs, one basic idea

Both NPAPI and PPAPI were ways for a web browser to hand part of a page over to a separate piece of native software — a plugin — that the browser itself didn't understand. Silverlight, Flash, Java applets, and PDF viewers all reached the page this way. The difference between the two APIs is mostly about trust and isolation: how much the browser let the plugin do, and how badly things went when the plugin misbehaved.

NPAPI: the old, powerful, dangerous one

NPAPI — the Netscape Plugin Application Programming Interface — dates back to the Netscape era of the 1990s. An NPAPI plugin was native code with broad access to the machine it ran on. That power is exactly why it was retired: Google's announcement of the final countdown for NPAPI described it as a 1990s-era architecture that had become a leading cause of hangs, crashes, and security incidents. A crashing plugin could take the page or the browser down with it — which is why so many people remember the "Silverlight plugin has crashed" bar. MDN's plugin glossary entry documents how browser vendors deprecated and then removed this whole plugin model. Chrome finished removing NPAPI in September 2015, and Mozilla ended NPAPI plugin support in Firefox as well. The longer story is in what NPAPI was and why browsers dropped it.

PPAPI: Google's sandboxed redesign

PPAPI — the Pepper Plugin API, often just called "Pepper" — was Google's attempt to keep the useful part of plugins while fixing the dangerous part. A PPAPI plugin ran inside Chrome's sandbox, isolated from the rest of the system, with a much narrower, better-defined interface to the browser. The practical significance: Chromium's NPAPI deprecation guide notes that Flash was unaffected by the NPAPI removal precisely because Chrome ran a Pepper-based Flash — which is why Flash outlived the NPAPI purge in Chrome while Silverlight and Java did not.

PPAPI's limitation was adoption. It was essentially a Chrome technology; other browser makers didn't take it up, so a plugin vendor porting to Pepper reached Chrome users and nobody else.

Why this mattered for Silverlight specifically

Silverlight only ever existed as an NPAPI plugin (plus an ActiveX control for Internet Explorer). There was no Pepper version of Silverlight, so when Chrome dropped NPAPI, Silverlight had no bridge to keep working there — while Pepper Flash sailed on for years. This one architectural fact explains most of the "Silverlight works in nothing but old Internet Explorer" experience, and it compounds with the product's own end of support in October 2021.

Where both APIs ended up

Neither API has a future. NPAPI is gone from every major browser, and Pepper was only ever a transitional measure for a shrinking set of plugins; the web platform ultimately replaced the plugin model itself rather than picking a winner between the two. Capabilities that once required native plugins — fast code execution, video, rich graphics — now live in the browser as open standards, with WebAssembly doing the "run compiled code fast" job that plugins once claimed. For teams holding a stranded Silverlight app, that standards-based path — not a plugin revival — is the way forward, starting with questions like whether Blazor is the Silverlight replacement.