Building Chrome Extensions in 2026: Manifest V3, Service Workers, and What Changed

Chrome extension development in 2026 requires Manifest V3. The old Manifest V2 is deprecated and being phased out. If you built extensions before: the architecture changed significantly. Background pages are gone. Service workers replace them. The permission model is stricter. Some APIs were removed.

Here is the practical guide to building Chrome extensions under Manifest V3.

What Changed from V2 to V3

Background pages → Service Workers: persistent background pages (always running) are replaced by service workers (event-driven, terminated when idle). This means: you cannot store state in memory (it disappears when the worker terminates), you must use chrome.storage for persistence, and long-running operations need different patterns.

Blocking webRequest → declarativeNetRequest: the powerful webRequest API (that could modify/block any network request) is restricted. You must declare URL patterns in advance. Runtime blocking is limited.

Remote code execution removed: you cannot execute code fetched from a remote URL. All code must be bundled in the extension package. This prevents malicious remote code injection but limits dynamic behavior.

Permissions model: more granular. Permissions can be optional (requested at runtime). Host permissions are separate from API permissions. Users have more control over what extensions can access.

The Extension Structure

A Manifest V3 extension typically contains:

manifest.json: the configuration file (name, version, permissions, scripts).

service-worker.js: background script (event listeners, API calls, state management).

popup.html/js: the popup UI (shown when clicking the extension icon).

content-scripts/: scripts injected into web pages (DOM manipulation, page interaction).

options.html/js: settings page for the extension.

Service Worker Lifecycle

The service worker: starts when an event fires (browser action click, alarm, message), runs the event handler, and terminates after ~30 seconds of inactivity.

Critical implication: do not store state in variables. Between events, the service worker terminates and restarts. All variable state is lost.

State management: use chrome.storage.local for persistent data (survives extension restart), chrome.storage.session for session data (survives service worker restart but not browser restart), and message passing for communication between service worker and UI components.

Building a New Tab Extension

We built an extension for AIDToolStack that replaces the new tab page with a developer tools dashboard. Here is the architecture:

manifest.json: declares chrome_url_overrides for newtab, permissions for storage and bookmarks, and the service worker for background operations.

newtab.html: the HTML page displayed on new tabs. Loads JavaScript that renders the dashboard UI (favorite tools, recent bookmarks, quick search).

service-worker.js: handles periodic data sync (fetching updated tool information), manages notifications, and coordinates between the popup and new tab page.

Content Scripts: Interacting with Web Pages

Content scripts run in the context of web pages. They can: read and modify the DOM, listen to page events, and communicate with the service worker via chrome.runtime.sendMessage.

They CANNOT: access Chrome extension APIs directly (only a subset), modify the extension's UI, or access variables from the page's JavaScript context (isolated world).

Use content scripts for: adding UI elements to existing pages, extracting information from pages, and modifying page behavior (with user consent).

Popup UI Development

The popup (shown on extension icon click): is an HTML page with its own JavaScript context, has limited size (max 800px wide, 600px tall), closes when the user clicks elsewhere (do not use for long-running operations), and communicates with the service worker via chrome.runtime.sendMessage.

Modern popup development: use a JavaScript framework (React, Svelte, Vue) bundled with Vite or webpack. The popup is just a small web page. Build it with the same tools you use for web development.

Our stack for the AIDToolStack extension popup: HTML (static structure), vanilla JavaScript (lightweight — no framework overhead for a small popup), and Tailwind CSS (consistent styling with the main application).

Storage API

chrome.storage.local: unlimited storage (with unlimitedStorage permission), persistent across browser restarts, and async API (use Promises or async/await).

chrome.storage.sync: synced across devices where the user is logged into Chrome, limited to 100KB total (8KB per item), and useful for user preferences that should roam.

Pattern: store configuration in sync (roams across devices) and store data in local (too large for sync, device-specific).

Permissions Best Practices

Request minimal permissions: only what your extension actually needs. Users see permissions on install and judge trustworthiness. Excessive permissions reduce installation rates.

Use optional permissions: request permissions at the point of need. Instead of requesting all host permissions upfront: request specific site access when the user activates a feature that needs it.

Avoid "access all sites" (host_permissions: [""]): this requires the most trust. If your extension only needs access to specific sites: declare only those.

Publishing to Chrome Web Store

Requirements: a Chrome Web Store developer account ($5 one-time fee), extension packaged as a ZIP file (not CRX), privacy practices disclosure (what data you collect, how you use it), and compliance with Chrome Web Store policies.

Review process: Google reviews all extensions before publishing. Expect 1-5 business days. Common rejection reasons: insufficient privacy policy, excessive permissions not justified by functionality, and policy violations (ads, malware, spam).

Tips for smooth review: provide clear privacy policy, justify every permission in the description, include screenshots showing functionality, and respond promptly to reviewer questions.

Testing Extensions

Load unpacked: during development, load your extension from the local directory (chrome://extensions → Developer mode → Load unpacked). Changes to HTML/CSS reload automatically. Service worker changes require clicking "reload."

Debugging: service worker: inspect from chrome://extensions (click "service worker" link). popup: right-click popup → Inspect. content scripts: regular DevTools on the page where they run.

Automated testing: use Puppeteer or Playwright with the extension loaded. Test: popup behavior, content script injection, and service worker event handling.

Performance Considerations

Extension startup: users expect instant response when clicking the extension icon. Keep the popup lightweight. Do not load heavy frameworks or make network requests during popup initialization.

Service worker efficiency: keep event handlers fast. Long operations block other events. Use alarms for periodic work (not setInterval — service workers terminate). Batch storage operations (multiple writes in one call).

Content script impact: injecting scripts into every page affects browser performance. Limit content scripts to pages where they are needed (use matches patterns in manifest). Minimize DOM manipulation.

Migration from V2

If migrating an existing V2 extension: replace background.page with service_worker in manifest, convert persistent background state to chrome.storage, replace blocking webRequest with declarativeNetRequest, update any remote code execution to bundled code, and test thoroughly (service worker lifecycle creates new edge cases).

The migration is not trivial for complex extensions. Plan 1-2 weeks for a medium-complexity extension. The Chrome team provides a migration guide with specific API replacements.

The Extension Ecosystem in 2026

Despite Manifest V3 controversy (developers disliked the reduced power): extensions remain vital. They extend browser functionality in ways no other technology can. Build extensions that: solve specific problems for users, respect user privacy and security, work within V3 constraints (they exist for good reasons), and provide value that justifies the trust users place in installing them.