Browser Extension Development

Browser extension development in 2026 looks different from even two years ago, for two reasons that compound each other: Manifest V3 is now fully enforced, and AI-powered extensions have become one of the most-used extension categories on the web.

Manifest V3 is no longer optional

MV2 extensions simply don't work in Chrome anymore — as of 2026, it's effectively a legacy format. Microsoft Edge started its own consumer transition away from MV2 in August 2026, aiming to complete the shift to MV3 by year's end. If you're building or maintaining a Chrome or Edge extension today, MV3 isn't a future migration to plan for — it's the only option.

The core technical changes in MV3 that reshape how extensions are built:

• Service workers replace persistent background pages. Background scripts no longer run continuously — they terminate when idle and wake up on events, which means extension logic that assumed a long-lived background context needs to be rewritten around ephemeral, event-driven execution.
• declarativeNetRequest replaces blocking webRequest. Extensions that modify or block network requests (ad blockers being the obvious example) can no longer intercept and mutate requests imperatively in real time — they declare rules upfront instead. This is the single biggest source of friction for ad-blocker and privacy-extension developers moving to MV3.
• Stricter Content Security Policy. Remotely hosted code is banned outright — all executable code has to ship inside the extension package, which closes off a class of dynamic-loading patterns that used to be common.
• Explicit host permissions. Permissions are more granular and visible to users, which is good for user trust but means more upfront design work around exactly what your extension needs access to.

The AI extension renaissance

The forced MV3 migration happened to coincide with a surge in AI-powered browser extensions. ChatGPT, Claude, and Perplexity extensions now have millions of users, and the Side Panel API — introduced as part of the MV3-era extension surface — has become the default canvas for chat-style UIs docked alongside whatever page the user is on.

The genuinely useful capability here is contextual: an extension can read the content of the page a user is currently viewing and send that context to an LLM without the user needing to copy-paste anything. That's a real, distinct advantage extensions have over standalone web apps — no other surface has that same low-friction access to "whatever the user is currently looking at."

What to build with in 2026

The current recommendation for new extension projects is to start with a framework like WXT or Plasmo rather than hand-rolling the manifest and build tooling from scratch — both handle a lot of the MV3 boilerplate (service worker lifecycle, hot reload, cross-browser manifest generation) that used to eat significant development time. From there, the core things worth learning deeply are Manifest V3's permission model, the service worker execution model, and the Side Panel API if you're building anything chat- or assistant-shaped.

The ecosystem fork worth knowing about

Not every browser followed Chrome's lead at the same pace. Firefox and Brave still fully support MV2, which matters specifically for power users who rely on extensions doing things MV3 makes harder — particularly advanced ad and content filtering. If your extension's core value proposition depends on the blocking webRequest API, it's worth being honest with yourself about whether Chrome is even the right primary platform anymore, versus building for Firefox first and treating Chrome as a reduced-functionality secondary target.

Practical takeaways

• Assume MV3 is the baseline for any new Chrome or Edge extension — there's no MV2 fallback path left.
• Design background logic around service worker termination from day one, not as a later refactor.
• If your extension touches network requests, prototype against declarativeNetRequest's rule limits early — it's more restrictive than blocking webRequest, and that constraint should inform your architecture, not be discovered late.
• If you're building anything AI-assistant-shaped, the Side Panel API plus page-context extraction is the pattern worth building around — it's the extension category with the clearest current user demand.

The security backdrop developers should design around

A relevant reality check for anyone building or distributing an extension in 2026: the Chrome Web Store has had genuine, large-scale malware problems this year, and it's worth understanding the pattern because it shapes both user trust and review scrutiny going forward. In April 2026, researchers identified a coordinated cluster of 108 malicious Chrome extensions tied to shared command-and-control infrastructure, collectively responsible for around 20,000 installs — the extensions posed as legitimate gaming, social media, and translation tools while secretly harvesting Google OAuth2 bearer tokens, monitoring Telegram Web sessions, and deploying persistent backdoors. A separate incident in February 2026 saw a previously trusted, featured extension called QuickLens — with roughly 7,000 users — get compromised through an ownership change, after which the new owner pushed a malicious update that abused the trust the extension had built up under its original developer.

The uncomfortable detail worth internalizing: despite these campaigns being identified and reported to Google, many of the malicious extensions remained available in the Chrome Web Store afterward, since existing review processes are built around scanning at initial submission rather than continuously monitoring for delayed-activation threats or post-acquisition malicious updates. Google has been rolling out enhanced detection aimed at catching these delayed-activation patterns specifically, but the gap illustrates a real risk for legitimate developers too: users are increasingly (and reasonably) wary of granting extensions the broad host permissions or OAuth access that a genuinely useful AI-assistant extension often needs, and that wariness is a headwind worth designing for directly — requesting the narrowest permission scope your extension can function with, and being explicit in your store listing about exactly what data you access and why, rather than assuming users will grant broad access on trust the way they might have a few years ago.

Sources: GroovyWeb — Chrome Extension Development 2026, Microsoft Edge Blog — MV3 Ecosystem, Chaos and Order — Browser Extension Development 2026, Hexnode — Malicious Chrome Extensions 2026, BleepingComputer — Chrome Web Store extensions caught stealing crypto