Engineering service
Chrome extension development
We build Manifest V3 Chrome extensions: background logic, content scripts, sign-in to your product, native messaging with desktop apps and company-wide rollout. We also rebuild old Manifest V2 extensions and prepare the package and permission justifications for Chrome Web Store review.
- 11+ years of experience
- 300+ projects delivered
- Remote team, clients worldwide
- NDA on request
Overview
What it is and when it fits
A Chrome extension is a small program that runs inside the browser. It can add a popup or side panel, change how pages look and behave, and react to browser events. Manifest V3, the only extension platform Chrome still runs, is stricter than the old one, and that shapes how the code has to be written.
The popup and content scripts are often the smaller part of the work. Much of the time goes into the pieces around them: the backend the extension calls, how users sign in, whether it has to talk to a desktop app, and how companies install it. We plan those before writing code, whether the job is a new extension, new features or a Manifest V2 rebuild.
Who this is for
- Product teams adding a browser companion to an existing web app or SaaS product.
- Teams whose Manifest V2 extension stopped working in Chrome and needs a Manifest V3 rebuild.
- Software vendors whose business customers need the extension force-installed and pre-configured by IT.
- Founders whose product is the extension and who need a codebase that can grow past a first version.
How it works
Architecture at a glance
How a Chrome extension is put together
Popup, side panel, options
The interface users see. Talks to the background through messages.
Service worker (background)
Handles events, alarms and network rules. Chrome stops it when idle, so state must live in storage.
Content script
Runs inside pages you choose. Can read and change the page, in an isolated JavaScript world.
Chrome extension APIs
tabs, storage, scripting, alarms, declarativeNetRequest, identity, native messaging
Web page
Content you do not control. Treat everything from it as untrusted input.
What we offer
What's included
Background logic and messaging
The service worker, the messages between it and the rest of the extension, and the calls to your backend, built for Chrome stopping the worker at any time.
Content scripts and interface
Scripts scoped to the sites you target and injected with chrome.scripting, plus the popup, options page or side panel users work in.
Request blocking and redirect rules
Rules built with declarativeNetRequest. Regular Manifest V3 extensions can still observe requests through webRequest, but not block or change them.
Sign-in and accounts
Sign-in to your product from the extension: chrome.identity for Google accounts, launchWebAuthFlow for other OAuth providers, or a session handed over from your web app.
Native messaging with desktop apps
A native messaging host so the extension can talk to your desktop app or local agent, with the host manifest registered on Windows, macOS and Linux.
Enterprise rollout
Force-install through Chrome Enterprise policies, settings pushed by IT through managed storage, and private or unlisted Chrome Web Store listings.
Manifest V2 to V3 rebuilds
Old Manifest V2 extensions rebuilt for the platform Chrome still runs, with each removed capability mapped to its Manifest V3 replacement first.
Chrome Web Store submission
Listing text, screenshots, privacy answers and permission justifications prepared for review, plus help answering reviewer feedback.
Builds for other browsers
The same codebase set up to build for Edge, Brave and Firefox, with the browser differences kept in a thin layer.
Deliverables
What you get
- 01
Source code and build
The full extension source in your repository, with a build that produces the same package every time and keeps all code inside it.
- 02
Permission plan
A table of every permission, the feature that needs it and the justification text to paste into the Chrome Web Store form.
- 03
Architecture notes
A map of the parts, the messages between them and what is kept in storage, so a new developer can find their way.
- 04
Test checklist
The cases we ran before release, written so your team can repeat them for every update.
- 05
Release package and listing
The upload package, listing text, screenshots and privacy practices answers for the Chrome Web Store, and the submitted release.
- 06
IT deployment guide
For company rollouts: the force-install policy values, a managed configuration schema and a one-page guide for administrators.
Compare
Manifest V2 vs V3: what changes
Chrome stopped running Manifest V2 extensions in 2025, and the Chrome Web Store removed the last Manifest V2 listings in August 2026. If your extension is still on V2, Chrome users have already lost it, so the rebuild is urgent. These are the changes that usually take the most work.
| Area | Manifest V2 (no longer runs in Chrome) | Manifest V3 |
|---|---|---|
| Background logic | A background page that could stay loaded and hold state in memory. | A service worker that Chrome stops when idle. State goes in chrome.storage and scheduled work uses alarms. |
| Network blocking | Blocking webRequest listeners could inspect and cancel requests in code. | Blocking and redirects are declared as declarativeNetRequest rules. Regular extensions can still observe requests with webRequest, but not block them. |
| Remotely hosted code | Extensions could load and run scripts from a server. | All code must ship inside the extension package. Behavior can still change through data, but not through downloaded code. |
| Script injection | tabs.executeScript, including running code from a string. | chrome.scripting.executeScript with a file or function that is part of the package. |
| Host access | Host permissions granted at install time. | Host permissions can be optional and controlled by the user, so the extension has to work when access has not been granted yet. |
Why it matters
What this gives you
Fewer "extension stopped working" tickets
The cases users hit, such as an idle browser, a revoked permission or a strict site, are tested before release instead of reported after it.
Store review with fewer surprises
Narrow permissions with a written reason for each, and no remotely hosted code, remove two common causes of rejected or delayed reviews.
One codebase for more browsers
When Edge, Brave or Firefox users ask for the extension, the groundwork is already there.
Code your team can take over
Typed code, a reproducible build and architecture notes, so your developers can keep shipping without us.
Our approach
How a Chrome extension project runs
Scope and permissions
We list what the extension must do, which sites it touches and which browser APIs that requires, then cut the permission list down.
You get: A feature list and a permission plan
Architecture
We decide what runs in the service worker, content scripts and interface, how sign-in and your backend fit in, and which messages pass between the parts.
You get: A component and message map
Build
We build in working slices that you can install and try in your own Chrome profile as the project goes.
You get: A working extension you can install and try
Test and harden
We test on the target sites, after the service worker has been stopped, with permissions denied or revoked, and on pages where extensions cannot run.
You get: A test checklist and fixes
Package and submit
We produce the release package, prepare the store listing and permission justifications, and handle review feedback with you.
You get: A submitted release and handover notes
When this is not the right fit
- You need to run code on chrome:// pages or in the Chrome Web Store itself. Chrome does not let extensions run there.
- You need to block or rewrite requests with your own code. Chrome only allows declarative rules for that. Firefox still allows blocking webRequest, which our Firefox extension development service covers.
- You want a one-off script for personal use. A userscript manager or bookmarklet is often enough.
Tech stack
Technologies we use
The engines, APIs and tools we use on this service.
Chrome Extensions APIchrome.storagechrome.scriptingdeclarativeNetRequestchrome.identityNative messagingChrome Side Panel APIChrome Enterprise policies
TypeScriptChrome Web StoreFAQ
Common questions
A new extension typically takes 3–8 weeks, depending on the number of features, the sites it works on and any backend or sign-in work. That is a typical range, not a quote. Chrome Web Store review comes on top, and its length varies with the permissions requested and the extension's history, so we leave room for it in the plan.
Very urgent. Current Chrome releases no longer run Manifest V2 extensions, so a V2 extension has already stopped working for Chrome users. Firefox still runs Manifest V2, so the V2 build can stay live there while the Chrome version is rebuilt.
Edge and Brave run Chrome extensions largely as they are, with some gaps: Google sign-in through chrome.identity.getAuthToken works only in Chrome, and Brave adds Shields and its own wallet. Firefox needs manifest and background changes. Safari needs the extension packaged inside an app. We cover each one: Edge, Brave, Firefox and Safari extension development.
Anything inside an extension package can be read by the people who install it, so secrets should never ship in the package. We keep them on a backend that the extension calls, and design that backend with authentication and rate limits.
Yes. Testing is part of every build we do. For an existing extension, browser and extension QA testing checks how it behaves across browsers, versions and managed setups, and an extension security audit looks for what an attacker could exploit.
Our services
Related services
Start a project
Build a production Chrome extension
Tell us what the extension has to do. We will assess the Manifest V3 limits, the permissions review and the architecture before you commit.
