How to Build Chrome Extensions with React, Vite & CRXJS in 2026

1. Why browser extensions are underrated

Browser extensions sit at a unique intersection: they have access to the pages your users already work in, they do not require a separate app install, and they can automate workflows that would otherwise require switching between multiple tabs and tools.

The market opportunity is significant. According to StatCounter (2026), Chrome holds approximately 65% of the global browser market share. The Chrome Web Store hosts over 125,000 extensions, and Chromium-based browsers (Edge, Brave, Opera, Arc) extend your potential reach even further. Extensions built for Chrome work across all of them with minimal modification.

For e-commerce businesses, this is particularly powerful. An extension can inject price comparisons directly into a competitor's page, automate bulk operations in marketplace dashboards, or add one-click invoicing to order management panels.

The ROI is often immediate: teams report saving 2-4 hours per day on repetitive browser-based tasks after deploying a custom extension. That is time that goes straight back into growing the business. For a deeper look at budgets and timelines, see our guide on the real cost of building a browser extension.

2. The stack: Vite + CRXJS + React + TypeScript

Our production stack has been refined over 100+ extension versions. Here is what we use and why. For a detailed comparison of extension frameworks, see our CRXJS vs Plasmo vs WXT comparison.

This stack gives us hot module replacement in content scripts (yes, you can see changes injected into a live page without refreshing), type-safe messaging between extension contexts, and a development experience that feels like building a normal React app.

// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import crx from '@crxjs/vite-plugin';
import manifest from './manifest.json';

export default defineConfig({
  plugins: [
    react(),
    crx({ manifest }),
  ],
});

Every extension we build is covered by end-to-end, integration, and unit tests. E2E tests verify the full user journey inside the browser, integration tests validate that content scripts, background workers, and popups communicate correctly, and unit tests lock down individual utilities and business logic. This layered approach catches regressions before they reach production.

3. Manifest V3: what actually changed

Manifest V3 (MV3) replaced V2 as the required format for Chrome extensions. Google has been sunsetting MV2, so all new extensions must use V3. Here are the changes that matter in practice:

The practical impact: if you are building new, MV3 is just how extensions work now - and we are MV3 native. Every extension we build starts on Manifest V3 from day one, not as a migration from V2. If you are migrating an older extension from MV2, the service worker transition is the biggest hurdle. We have done this migration for multiple clients and can help if you are stuck.

{
  "manifest_version": 3,
  "name": "My Extension",
  "version": "1.0.0",
  "action": {
    "default_popup": "src/popup/index.html"
  },
  "content_scripts": [{
    "matches": ["https://example.com/*"],
    "js": ["src/content/index.tsx"]
  }],
  "background": {
    "service_worker": "src/background/index.ts",
    "type": "module"
  },
  "permissions": ["storage", "activeTab"]
}

4. Content scripts and injecting React into pages

Content scripts are the most powerful part of Chrome extensions. They run in the context of web pages, meaning they can read and modify the DOM of any page the user visits (with the right permissions).

The challenge is injecting a full React component tree into an existing page without breaking it. This is exactly what our internal react-content-script-injector library solves:

Static sites are the easy case - inject once and you are done. The hard part is React and SPA apps where the DOM is constantly changing, routes shift without page reloads, and the host app might be running A/B tests that move or rename the elements you are targeting. This is where we specialize, and why we built this library.

5. Shadow DOM: style isolation that works

Style isolation is the single biggest pain point in content script development. Without it, your extension UI inherits the host page's styles - buttons look wrong, fonts change, spacing breaks. Conversely, your extension's CSS can accidentally restyle the host page.

Shadow DOM provides true encapsulation. Styles inside the shadow root do not leak out, and styles outside do not leak in. This is critical for production extensions that need to work across thousands of different websites with different CSS resets, frameworks, and conflicting class names.

Our react-content-script-injector handles Shadow DOM setup automatically, including the tricky parts: injecting Tailwind into the shadow root, handling font loading across the shadow boundary, and making portals (modals, dropdowns) work correctly within the shadow context. Because the library manages React Portals natively, the full React context - providers, state, theme - stays available inside every portal, so components rendered in Shadow DOM behave exactly like components in a normal React tree.

6. Messaging between contexts

A Chrome extension has multiple isolated JavaScript contexts: the content script (runs on pages), the background service worker, the popup, and options pages. They communicate via the Chrome messaging API.

In practice, you end up with a pattern similar to a client-server architecture: the service worker is your "server" (handling API calls, storage, and business logic), and content scripts / popup are your "clients" that request data and trigger actions.

With TypeScript, you can make messaging fully type-safe: a message of type "GET_PRICES" always returns a typed PriceData response. This eliminates an entire class of runtime errors that are hard to debug across contexts.

// messages.ts - Define typed message schemas
type MessageMap = {
  GET_PRICES: {
    request: { productId: string };
    response: { prices: number[]; currency: string };
  };
  UPDATE_SETTINGS: {
    request: { theme: 'light' | 'dark' };
    response: { success: boolean };
  };
};

// Type-safe sender (content script or popup)
async function sendMessage<T extends keyof MessageMap>(
  type: T,
  payload: MessageMap[T]['request']
): Promise<MessageMap[T]['response']> {
  return chrome.runtime.sendMessage({ type, payload });
}

// Usage - fully typed, autocomplete works
const { prices } = await sendMessage('GET_PRICES', {
  productId: 'sku-123'
});

7. Storage and state management

Extensions have their own storage APIs: chrome.storage.local for device-local data and chrome.storage.sync for data that follows the user across devices. Unlike localStorage, these are available in all extension contexts (content scripts, service worker, popup).

For complex state, we use a lightweight reactive store pattern: the service worker holds the source of truth, and content scripts subscribe to changes via chrome.storage.onChanged. This gives you real-time sync across all open tabs without any additional infrastructure.

One important caveat: chrome.storage.sync has strict size limits (102,400 bytes total, 8,192 bytes per item). For larger datasets, use chrome.storage.local and handle cross-device sync yourself if needed.

// content-script.ts - Subscribe to storage changes
chrome.storage.onChanged.addListener((changes, area) => {
  if (area === 'local' && changes.userSettings) {
    const newSettings = changes.userSettings.newValue;
    // React component re-renders automatically
    updateUI(newSettings);
  }
});

// service-worker.ts - Write once, all tabs update
await chrome.storage.local.set({
  userSettings: { theme: 'dark', language: 'en' }
});
// Every open tab receives the change event instantly

8. Deployment and distribution

There are four main distribution channels for Chrome extensions:

We handle the full deployment pipeline: build, package, submit, and iterate on review feedback. Our CI/CD automatically bumps extension and package versions, builds the artifact, and deploys directly to the Chrome Web Store - so every merge to main is a potential release. For testers, the same pipeline publishes installable builds to GitHub. For enterprise clients, we add group policy distribution on top. Read more about how we set this up in our CI/CD pipeline for browser extensions article.

9. Common mistakes we have seen

After building and reviewing dozens of extensions, these are the patterns that cause the most problems:

10. Frequently asked questions

Related articles