The Future of Chrome Extensions: What's Coming After MV3
Where Chrome extensions are headed in the next two years — built-in AI APIs, side panels, and the slow death of legacy permissions.
Manifest V3 was a step, not a destination. Chrome's extension platform is evolving fast, and the next two years bring some of the biggest changes since extensions were introduced.
Three shifts to plan for
- Built-in AI APIs — Chrome is shipping on-device Gemini APIs that extensions can call without sending data to a server.
- Side panel adoption — the side panel is replacing the popup for any extension with persistent UI.
- Tighter permission scoping — `<all_urls>` will eventually require per-site user activation.
What this means for builders
Extensions that lean into on-device AI, use the side panel, and ask for narrow permissions will outrank competitors in both the Web Store and user trust. Generic AI-API wrappers will get squeezed by extensions using Chrome's built-in models for free.
How ManifestGo is keeping up
Every Chrome platform update lands in ManifestGo's generation prompts within days. The extensions you generate today already use side panel APIs and narrow permissions by default.
The built-in AI APIs, specifically
Chrome's on-device AI surface is no longer experimental. The `LanguageModel` (Prompt API), `Summarizer`, `Translator`, `LanguageDetector`, and `Writer`/`Rewriter` APIs run Gemini Nano locally and are gated behind the `optional_permissions` or trial tokens depending on channel. Extensions declare `"permissions": ["aiLanguageModelOriginTrial"]` or use the stable APIs directly in Chrome 138+, and calls return a `ReadableStream` for token-by-token output — no API key, no network request, no per-token billing.
- `Summarizer.create()` — summarizes selected text or page content entirely on-device.
- `LanguageModel.create({ initialPrompts })` — general-purpose prompting against Gemini Nano.
- `Translator.create({ sourceLanguage, targetLanguage })` — offline translation without a translate.com-style API dependency.
- Availability check via `await Summarizer.availability()` returning `'available' | 'downloadable' | 'downloading' | 'unavailable'` — always branch on this before calling create().
Manifest changes worth tracking
MV2 extensions are fully removed from the Chrome Web Store for general users as of mid-2025; only enterprise-policy-forced installs still load them, and that carve-out is scheduled to shrink further. `manifest_version: 3` is now simply the floor, not a differentiator. Chrome has also started enforcing stricter Content Security Policy defaults — inline event handlers (`onclick="..."` in HTML) are blocked even with a custom CSP unless you explicitly opt in, which trips up extensions ported from older codebases.
Side panel is the default surface for 'always-there' UI
`chrome.sidePanel.setOptions({ tabId, path, enabled })` lets an extension show a different side panel per tab, and `chrome.sidePanel.open({ windowId })` can now be triggered from a user gesture in the background worker, not just the toolbar icon. This closed the biggest side panel limitation from 2024 — extensions can now open the panel programmatically after a context-menu click or keyboard shortcut.
Declarative Net Request keeps expanding
`declarativeNetRequest` rulesets now support session-scoped dynamic rules via `chrome.declarativeNetRequest.updateSessionRules`, useful for ad blockers and privacy tools that need per-tab rule changes without persisting them. The static rule limit remains 30,000 per ruleset for unpacked/enabled rulesets, with a global dynamic rule cap of 5,000 — extensions hitting `ERR_DYNAMIC_RULE_LIMIT_EXCEEDED` need to consolidate rules rather than requesting an increase, since there isn't one.
Quota and storage changes to plan for
- `chrome.storage.session` — in-memory, cleared on browser restart, useful for caching AI responses without persisting them.
- `chrome.storage.local` unlimited quota now requires the `unlimitedStorage` permission explicitly, or you hit the default ~10MB cap.
- IndexedDB inside a service worker is now stable for extensions needing structured local data beyond storage.local's limits.
How to build for where the platform is going
New extensions should default to the side panel over the popup for anything with more than one screen, call `availability()` before every built-in AI API use, and avoid `<all_urls>` in favor of `activeTab` plus optional host permissions requested at runtime via `chrome.permissions.request()`. ManifestGo's generated projects already default to this pattern, which matters because Chrome's Web Store review process increasingly flags manifests that request broad permissions up front instead of on-demand.
Frequently asked questions
Are Manifest V2 extensions completely gone in 2026?
For consumer Chrome, yes — MV2 extensions no longer load by default; only enterprises using the ExtensionManifestV2Availability policy can still force-install them, and that exception is being phased down further.
Do the built-in AI APIs cost money to use?
No — Summarizer, Translator, LanguageModel, and related APIs run Gemini Nano on-device, so there's no API key or per-call billing, though the model download itself uses local disk space on first use.
Can an extension detect if the on-device model isn't downloaded yet?
Yes — call the API's `availability()` method (e.g. `Summarizer.availability()`), which returns 'downloadable', 'downloading', 'available', or 'unavailable' so you can show a loading state or fallback.
