Browser extension development
Chrome, Firefox, and Edge extensions built for Manifest V3, from a team that has actually shipped and grown a live extension through the Chrome Web Store. Productivity tools, AI assistants, SaaS companion overlays, cross browser content tools. Architecture, MV3 compliance, AI integration, Web Store submission, post-launch maintenance.
Chrome has roughly 3.8 billion users worldwide (Backlinko / Statcounter, 2025). A browser extension puts your product inside that session with one click and no app store delay. Compare that to mobile, where you are fighting for a home screen slot against apps people already have. If you can build something people actually want to keep pinned in their toolbar, the distribution problem mostly solves itself.
why browser extensions are still worth building#
3.8 billion Chrome users, and growing#
The Web Store is the single largest software distribution channel by active user count for most product categories. One click to install. Your product lives in the browser, on every page, in every tab.
About 112,000 active extensions are listed on the Chrome Web Store as of 2024. Eighty-six percent have fewer than 1,000 users (Chrome-Stats, 2024). Most of what is out there is half-finished or poorly distributed. That is actually encouraging if you are planning to build something with real product thinking behind it.
On the enterprise side, the numbers are even more interesting: 99% of enterprise employees have at least one extension installed and 52% have more than ten (LayerX, 2025). B2B tools delivered as extensions, like CRM overlays and sales intelligence sidebars, meet people where they already spend their day. No separate app to install, no login redirect, no context switch.
the Manifest V3 transition most shops got wrong#
Chrome's shift from MV2 to MV3 was the biggest platform change in the extension ecosystem's history. Persistent background pages got replaced with service workers. Content Security Policy got tighter. Remote code execution was blocked entirely. Network request modification was restructured around declarative rules. As of August 2025, 73.4% of Chrome extensions had migrated; everything still on MV2 was disabled in Chrome 138/139 (Chrome for Developers, 2025).
A lot of development shops are still writing MV2-style code because that is what their documentation and internal knowledge covers. Our codebase has been MV3-native since the APIs stabilized. Service worker lifecycle management, storage patterns that replaced persistent background pages, offline state handling. No shimming old patterns onto a new runtime.
where AI extensions are heading in 2026#
The AI browser extension market was valued at $1.5 billion in 2023 and is projected to reach $7.8 billion by 2031 (market research, 2024). The reason is simple enough: an AI model that can see what is on the current page and what the user just highlighted gives meaningfully better answers than a chatbot sitting in a separate tab with no context.
The tricky part is the plumbing. LLM API calls from an extension hit CORS restrictions. API keys cannot live in content scripts because they are trivially extractable from the installed package. Users expect sub-second responses. Building GlanceAI meant working through every one of these constraints on a live product with real users filing bugs.
what we build#
productivity and workflow tools#
Tab managers, focus tools, form automation, keyboard shortcut systems, page annotation. The kind of extensions that sit quietly in the browser and shave ten seconds off something you do fifty times a day. Architecturally these tend to be simple. The ones with staying power are the ones where someone actually thought about the workflow instead of just wrapping an API.
AI reading and research assistants#
This is the category GlanceAI falls into. Summarize a page, pull out the relevant bits, assist with writing, surface context from a knowledge base while someone browses. LLM calls go through a backend proxy, never direct API key exposure in the extension package. Context capture happens via content scripts; responses render in a sidebar or overlay without breaking the page.
content tools and DOM-level customization#
Sometimes you need to modify someone else's website. Hide elements, reformat a layout, inject custom UI, bolt functionality onto an existing web app. The hard part is not the modification itself; it is isolation. Your content script's execution context and the page's JavaScript environment need to stay cleanly separated. Pages that aggressively manage their own DOM (most modern SPAs) will fight you if the boundary is not airtight.
SaaS companion extensions and CRM overlays#
Picture a CRM sidebar that pops up when someone visits a prospect's LinkedIn profile. Or a support tool that identifies the customer from the URL and pulls their ticket history. These B2B extensions surface your product's data alongside whatever the user is already looking at. They need authenticated API integration, secure token storage in chrome.storage, and session management that survives browser restarts without logging people out.
cross browser extensions (Chrome, Firefox, Edge)#
Built to the WebExtensions API standard for distribution across all three browsers from a single codebase. Browser-specific shims handle the differences in permissions, storage APIs, and service worker support. Everything gets tested on all three platforms before submission.
how we build it#
Manifest V3 architecture and service workers#
MV3 service workers replace the persistent background page. They are event-driven and the browser can terminate them whenever they are idle. That one change breaks a lot of assumptions. Anything that used to live in memory now needs explicit persistence. Long running work needs keepalives or needs to be offloaded to the backend entirely.
The service worker layer has to account for its own mortality. Message queuing for operations that arrive while the worker is spun down. chrome.storage for anything that has to survive restarts. Alarm-based scheduling for periodic tasks. Miss any of this and you get an extension that works perfectly in development, then silently drops messages in production when Chrome decides the worker has been idle too long.
content scripts, background workers, and side panels#
Content scripts inject into page context. They can read and modify the DOM but run in an isolated JavaScript environment. The side panel API (Chrome 114+) gives you a persistent UI surface that does not overlay the page. Background service workers handle API calls, storage, and tab-to-tab communication.
The mapping matters. Content scripts handle page interaction. Service workers handle state and APIs. Side panel for persistent UI. Popup for quick interactions. When this architecture is wrong the extension breaks quietly on browser updates. Debugging a silently failing service worker while trying to reproduce an issue a user reported on a page you cannot access is not a fun afternoon.
cross-origin and permissions strategy#
Over-permissioned extensions get reviewed harder by the Web Store team and make users suspicious at install time. Host permissions, content script matches, and optional permissions all get scoped to the minimum set that actually does the job.
Cross-origin API calls from content scripts are blocked by CORS. Those calls need to go through the service worker's fetch or through a backend proxy. This is something that needs to be decided during architecture, not discovered when a CORS error surfaces in QA and someone has to restructure the call chain.
AI and LLM integration inside extensions#
API keys in the extension package are a non-starter. Anyone with the extension installed can extract them. AI calls go through a backend proxy that the extension authenticates against. That means building a backend service, a token issuance mechanism, and rate limiting with usage tracking on top of the extension itself.
On-device inference is now an option too. Chrome's built-in Gemini Nano API (Chrome 127+, Prompt API) works for use cases where you want offline capability or lower latency, or where the user's data should not leave the device. Whether to use on-device AI, a remote API, or both is a product decision that depends on the use case.
cross browser compatibility with WebExtensions API#
The WebExtensions API gives you a common surface across Chrome, Firefox, and Edge, but the implementations diverge in ways that will bite you if you are not testing on all three. Firefox uses browser.* with native Promises. Chrome uses chrome.* with callbacks (plus a Promise wrapper in MV3). Storage behavior differs. Service worker support differs. Side panel availability differs. A polyfill layer and some browser-specific conditionals handle most of it; test builds get verified on each target.
from code to Chrome Web Store: full lifecycle#
Web Store submission and review#
First-time submissions to the Chrome Web Store are manually reviewed. Extensions requesting sensitive permissions (host permissions for all URLs, identity API, tabs API) get more scrutiny. Remote code execution is prohibited in MV3. A privacy policy is required if the extension touches user data.
Extensions get rejected for permissions that look broader than what the extension actually does, missing privacy policies, content policy violations in store listing screenshots, and obfuscated code. The time to audit against the Developer Program Policies is before you submit. The rejection email does not come with helpful feedback.
GlanceAI went through this process repeatedly on the way to 24,700+ users. Each version update goes through review again. Managing that pipeline while also responding to user feedback from thousands of installs taught us where the Web Store process catches people.
monetization: freemium, subscription, and one-time models#
Freemium with premium tiers behind an auth gate is the most common model. Free tier drives installs; subscription converts the power users. One-time payment through Stripe or Paddle works well for utility extensions with a clear, immediate value to the buyer. Enterprise licensing through direct sales works for B2B tools where the buyer can calculate an ROI.
Billing, entitlement checks, and user account infrastructure go into the initial architecture. Retrofitting a payment model onto a shipped extension is painful. It usually means rewriting authentication, and sometimes the service worker state model too.
post-launch iteration and version management#
Chrome auto-updates installed extensions when a new version hits the Web Store, typically within a day or three. Firefox and Edge have similar mechanisms. After launch, maintenance means keeping up with Chrome API changes (they do break things), triaging user feedback, and going through review for each update.
Retainer support is available for clients who want ongoing iteration. Full handoff documentation is also part of every project, so your team can take over whenever they are ready.
GlanceAI: what we shipped#
GlanceAI is a Chrome extension we built and published internally. An AI browsing assistant that reached 24,700+ active users through organic Web Store growth with no paid acquisition. MV3 from the start, LLM integration through a backend proxy, freemium model.
The reason we talk about it is not the user count. It is that building a real extension exposed every problem this page describes: service workers dying at the worst time, Web Store rejections over permission scope, CORS issues with LLM proxies, users on Chrome versions that behaved differently than what we tested against. Most teams claiming to build browser extensions have not shipped one to a user base large enough to surface those problems.
See the GlanceAI project page for the full story.
what a project looks like#
discovery and scoping#
A requirements session kicks things off: what the extension needs to do, which browsers, which page types it interacts with, backend dependencies, monetization model, distribution plan.
That turns into an architecture document covering service worker structure, content script injection patterns, the permissions manifest, backend requirements if AI or auth is involved, and a feature scope with timeline.
build and QA#
Two-week sprints. Dev build delivered for testing at each sprint boundary. Cross browser testing on Chrome, Firefox, and Edge as applicable. QA covers install/uninstall lifecycle, service worker restart behavior, content script injection on target URLs, storage persistence, and the specific user flows the extension supports.
For extensions with content scripts, script injection cannot perceptibly slow down page load. API call latency gets measured and brought down before submission.
publishing and handoff#
Web Store listing assets (screenshots, promotional images, description copy) are prepared as part of the launch package. The initial submission review and any policy questions from the review team are handled before launch.
Handoff: full codebase, deployment credentials, developer dashboard access, documentation covering architecture, update process, and maintenance procedures.
FAQ#
How much does it cost to build a custom browser extension?
Simple single-browser extensions with no backend run $3,000 to $8,000. Add auth, API integration, and cross browser support and you are looking at $8,000 to $18,000. AI extensions with a backend proxy, monetization, and full Web Store publishing run $18,000 to $35,000+. The spread comes from real architecture differences, not padding.
What is Manifest V3 and why does it matter for Chrome extensions?
MV3 is Chrome's current extension platform spec. It replaced MV2 by swapping persistent background pages for ephemeral service workers, blocking remote code execution, and restructuring how network request modification works. Extensions still on MV2 were disabled in Chrome 138/139 as of August 2025. There is no building on MV2 anymore.
Can a browser extension work on Chrome, Firefox, and Edge at the same time?
Yes. The WebExtensions API provides a common interface across all three. There are namespace differences (browser.* vs chrome.*), service worker support varies, and sidebar availability is not uniform, but a compatibility layer handles most of it. One codebase, three separate store submissions (Chrome Web Store, Firefox Add-ons, Microsoft Edge Add-ons).
How long does it take to develop and publish a Chrome extension?
Depends on complexity. A simple single-purpose extension takes 2 to 4 weeks of development plus a few days for Web Store review. Mid-complexity with auth and API integration runs 4 to 8 weeks. A full AI extension with backend and monetization takes 8 to 14 weeks. First-time Web Store reviews can take up to a week, depending on what permissions you request.
What AI features can be added to a browser extension?
Page summarization, writing assistance, research context surfacing, sidebar chat with page awareness. All of these need a backend proxy for the LLM API calls because you cannot safely expose API keys in the extension package. Chrome 127+ also supports on-device inference through the built-in Prompt API, which handles offline and privacy-sensitive use cases without a backend round trip.
Ready to build your extension? Talk to our team. Or review our agentic AI services if AI integration is central to what you are building.
