Engineering service
Chrome Browser Extension Development
We build production Chrome extensions on Manifest V3: service-worker architecture, complex API integrations, authentication, native messaging and enterprise workflows. That includes migrating existing Manifest V2 codebases and passing Chrome Web Store review.
- 15+ years of experience
- 300+ projects delivered
- Clients worldwide
- NDA available
Overview
What this is, and when it is the right call
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. Under Manifest V3, the current extension platform, the structure is stricter than it used to be, and that shapes how the code has to be written.
We build Manifest V3 extensions with background logic that survives being stopped, permissions kept as narrow as the feature allows, and code that is ready for store review. That covers new builds, Manifest V2 migrations, and adding features to an extension that already exists.
Who this is for
- Product teams adding a browser companion to an existing web app or SaaS product.
- Teams with a Manifest V2 extension that needs to move to Manifest V3.
- Companies that need an extension to read or change pages on specific sites, with permissions users can understand.
- 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 Manifest V3 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. The browser 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.
Browser extension APIs
tabs, storage, scripting, alarms, declarative network rules, identity
Web page
Content you do not control. Treat everything from it as untrusted input.
What we offer
What we engineer: Chrome Browser Extension Development
Service worker background logic
Background code structured around chrome.storage and alarms so it behaves correctly when the browser stops and restarts the service worker.
Content scripts for target sites
Scripts scoped to the pages your extension needs to read or modify, injected through chrome.scripting rather than string-based execution.
Popup, options and side panel UI
Interface work for the popup, options page and Chrome side panel, wired to the background through message passing.
declarativeNetRequest rule sets
Request blocking and redirect rules declared up front, since Manifest V3 does not allow regular extensions to inspect and cancel requests through webRequest.
Chrome Web Store submission support
Listing content, screenshots and permission justifications prepared for review, plus help responding to reviewer feedback.
Manifest V2 to V3 migration
Moving background logic into a service worker, replacing blocking webRequest with declarativeNetRequest, and removing any remotely hosted code.
Deliverables
What you get
- 01
Manifest and permission plan
A manifest that requests the fewest permissions the features need, with host access optional or user-controlled where the design allows it.
- 02
Service worker logic
Background code that keeps its state in chrome.storage, uses alarms for scheduled work, and behaves correctly when the worker restarts.
- 03
Content scripts and interface
Content scripts for the pages you target, plus a popup, options page or side panel wired to the background through messages.
- 04
Network rules
Request blocking or redirecting built with declarativeNetRequest rules, since blocking through webRequest is not available to regular Manifest V3 extensions.
- 05
Packaged build and store listing support
A reproducible build with all code inside the package, plus help preparing the permission justifications and listing details the Chrome Web Store asks for.
- 06
Documentation and handover
Notes on the architecture, the message flow between parts, and how to build, test and release, so your team can maintain it.
Compare
Manifest V2 vs V3: what changes
Chrome is phasing out Manifest V2, so check Chrome's current timeline before deciding how much time a migration needs. These are the differences that usually cost the most work.
| Area | Manifest V2 | Manifest V3 |
|---|---|---|
| Background logic | A background page that can stay loaded and hold state in memory. | A service worker that the browser stops when idle. State goes in chrome.storage and scheduled work uses alarms. |
| Network blocking | Blocking webRequest listeners can inspect and cancel requests in code. | Rules are declared up front with declarativeNetRequest. Blocking webRequest is not available to regular extensions. |
| 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
Service worker state handled correctly
State lives in chrome.storage and scheduled work uses alarms, so the extension keeps working after the service worker is stopped and restarted.
Permissions scoped to store review
The manifest requests only what the features need, with host permissions kept optional where the design allows it.
A clear migration path off Manifest V2
If you are moving off Manifest V2, we map each removed capability to its Manifest V3 replacement before writing code.
A build ready for review
All code ships inside the package, with no remotely hosted scripts, matching what Chrome Web Store review expects.
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, and define the messages between them and the data kept in storage.
You get: A component and message map
Build
We build in working slices, testing each in a real browser profile, including cases where the service worker has been stopped and restarted.
You get: A working extension you can install and try
Test and harden
We check behavior on the target sites, on pages where extensions cannot run, and with permissions denied or revoked.
You get: A test checklist and fixes
Package and submit
We produce the release package, prepare the store listing details and permission justifications, and handle review feedback with you.
You get: A submitted release and handover notes
When this is not the right fit
A few cases where this approach may not be the best choice for you.
- You need to run code on chrome:// pages or the Chrome Web Store itself. Extensions are not allowed to run there.
- You need to rewrite every request in arbitrary code. Manifest V3 limits this to declarative rules.
- 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 behind our chrome browser extension development work.
Chrome Extensions APIchrome.storagedeclarativeNetRequestchrome.scriptingService WorkersChrome Side Panel API
JavaScript
TypeScriptChrome Web StoreFAQ
Questions engineers ask before starting
It varies with the permissions requested, the extension's history and how clear the listing is, so we do not treat any review time as fixed. Plan release dates with room to spare, and check the store's current rules before relying on a schedule.
Our services
Related services
Explore more services that work alongside this one.
Talk to a Browser Engineer
Build a Production Chrome Extension
Tell us what the extension has to do. We will assess the Manifest V3 constraints, the permissions review and the architecture before you commit.
