Browser extensions
Hire Chrome extension developers who ship Manifest V3 extensions that pass review
Our Chrome extension developers design, build and publish extensions that run on Manifest V3, ask only for the permissions they need and get through Chrome Web Store review. One codebase also covers Edge, Brave, Opera and other Chromium browsers.
- Manifest V3 from day one, with service workers done right
- Store listing, privacy forms and review handled for you
- One build for Chrome, Edge, Brave and Opera
Overview
What Chrome extension developers do, and why Manifest V3 changes the job
A Chrome extension is a small program that lives inside the browser. It can add a button to the toolbar, open a side panel next to the page, read or change the pages a user visits, and talk to your own backend. Sales tools, password managers, AI writing helpers, price trackers and internal company tools are all built this way. Because the extension sits where your users already spend their day, it is one of the cheapest ways to put your product in front of them every hour.
Chrome now only runs Manifest V3 extensions. Manifest V3 replaced the old always-on background page with a service worker that Chrome starts when an event arrives and shuts down when it goes quiet. It also bans remotely hosted code, so every line of logic must ship inside the package Google reviews. Network blocking moved to the declarativeNetRequest API. Many tutorials and older codebases still assume the old model, which is why extensions built by generalist web developers often lose state, miss events or get rejected.
Our Chrome extension developers know the platform rules as well as the code. They design around the service worker lifecycle, keep state in chrome.storage instead of global variables, split work cleanly between content scripts, the popup, the side panel and the background, and pass messages between them safely. They also know the store side: the single purpose policy, the privacy practices form, permission justifications and how a broad host permission can slow review.
When you hire Chrome extension developers from Dware, you get senior engineers who have shipped to the Chrome Web Store before. They work in your repository, your code is reviewed by a second senior engineer on every change, and you own the code, the store listing and the developer account from the first day.
What we build
Chrome extension development services we offer
From a first prototype to a polished product with thousands of users, our Chrome extension developers cover every part of the job, including the store work most teams forget.
Custom Chrome extension development
We build new extensions from scratch, from simple toolbar buttons to full products with accounts, sync and payments handled by your backend. You get a clean TypeScript codebase that is easy to extend.
Manifest V2 to Manifest V3 migration
We move background pages to service workers, replace blocking webRequest with declarativeNetRequest rules and remove remote code. We then test every flow so nothing silently breaks for existing users.
Content scripts and page automation
We write content scripts that read and change pages reliably, even on single-page apps that rebuild the DOM constantly. We use isolated worlds, mutation observers and careful selectors so updates to the target site do not break your extension.
Popups, side panels and options pages
We design the interface your users actually touch: a fast popup, a persistent side panel using the chrome.sidePanel API, and a clear options page. We usually build these in React or Svelte with a small bundle.
AI features inside the browser
We connect your extension to language models through your own backend, so API keys never ship in the package. Typical features are page summaries, reply drafting, data extraction and smart autofill.
Chrome Web Store listing and review
We prepare the listing, screenshots, privacy practices answers and permission justifications, then handle review and any rejection. We also set up staged rollouts so a bad release reaches only a small share of users.
Enterprise and private extensions
We build internal tools and publish them as private or unlisted items, or force-install them for your staff through Google Workspace and Chrome policies.
Edge, Brave and Opera support
Brave and Opera can install from the Chrome Web Store, and we publish the same build to Microsoft Edge Add-ons. We test the small differences between Chromium browsers before each release.
Our process
How our Chrome extension developers build your extension, step by step
Every Chrome extension project follows the same clear path. Each step has concrete outputs, so you always know what is done and what comes next.
- 1
Discovery: purpose, permissions and policy check
We start with a short call to understand what the extension must do and who will use it. We then write down its single purpose in one sentence, because the Chrome Web Store requires that every extension has one narrow, clear purpose. We list each permission and host pattern the features need and check them against store policies before any code exists. This is where we catch ideas that would get rejected, like bundling unrelated features or reading every site when only one is needed.
What you get
- One-line single purpose statement
- Permission and host access plan
- Policy risk notes
- Free, fixed quote
- 2
Architecture: mapping the extension's parts
We decide what runs where. The service worker handles events, alarms and calls to your API. Content scripts only touch the page, and the popup or side panel only shows the interface. We define typed messages between these parts with chrome.runtime messaging and long-lived ports where needed, and plan what goes into chrome.storage.local, storage.sync and storage.session. If the extension needs DOM APIs in the background, such as audio or clipboard work, we plan an offscreen document.
What you get
- Component and message map
- Storage and state plan
- manifest.json draft
- 3
Project setup and tooling
We set up a TypeScript project with a modern extension build tool such as WXT, Plasmo or Vite with CRXJS, so the team gets hot reload and a clean production bundle. We add ESLint, Prettier, @types/chrome and a CI pipeline in your repository. Separate development and production builds use different extension keys and API endpoints, so testing never touches real user data.
What you get
- Repository with build pipeline
- Dev and production build configs
- Unpacked build you can load today
- 4
Build in short, reviewable increments
We build feature by feature and send you a new unpacked build or a private store test listing every week. Service worker code is written to survive shutdowns: no state in global variables, alarms instead of long timers, and every listener registered at the top level so Chrome can wake the worker. Content scripts are scoped to exact URL patterns, and optional permissions are requested at the moment a feature needs them. Every pull request gets a senior code review before it is merged.
What you get
- Weekly test builds
- Pull requests with senior review
- Short written progress updates
- 5
Testing in real browsers
We unit test logic with Vitest or Jest and mock the chrome APIs. We then run end-to-end tests with Playwright or Puppeteer, which load the real extension into Chromium and click through the popup, side panel and content scripts on real pages. We also force the service worker to stop in the middle of flows to prove that state survives. Before release we check Chrome, Edge and Brave by hand on the target sites.
What you get
- Unit and end-to-end test suite
- Service worker restart tests
- Cross-browser test checklist
- 6
Chrome Web Store submission and review
We prepare the listing text, icons, screenshots and promo tiles, write the privacy policy section and fill in the privacy practices tab honestly, including the data use certification. Every permission gets a clear justification, which is often the difference between a review of days and one of weeks. If the reviewer rejects the item, we read the violation reference, fix the cause and resubmit. For updates we use the Chrome Web Store API from CI and a percentage rollout.
What you get
- Complete store listing
- Privacy practices answers
- Approved, published extension
- 7
Launch, monitoring and ongoing support
After launch we watch error reports from the service worker and content scripts, user reviews and uninstall feedback. Chrome releases a new stable version roughly every four weeks, so we test against Beta and Canary to catch breaking changes early. Target websites change too, and we fix broken selectors quickly. We can stay on as your extension team or hand over with full documentation.
What you get
- Error monitoring setup
- Release and rollback runbook
- Post-launch support plan
Want this process for your project? Tell us what you're building and get a free, fixed quote.
Get a free quoteTechnical expertise
Chrome extension development expertise that keeps you out of trouble
These are the areas where Chrome extensions most often break or get rejected, and where experienced developers make the biggest difference.
Service worker lifecycle
In Manifest V3 the background is a service worker that Chrome can stop after about thirty seconds without events. Any value held in memory disappears, and timers stop. We keep state in chrome.storage, schedule work with chrome.alarms and register every event listener at the top level so it fires after a restart. Long tasks are split into steps that can resume, so a shutdown never loses a user's work.
Permissions and user privacy
Each permission adds a warning on the install screen, and adding a new one in an update can disable the extension until users approve it. We use activeTab where possible, request host access only for the sites that matter and move extra access to optional_permissions requested at runtime. Sensitive data is sent only over HTTPS to your own servers, and we follow the store's limited use rules for anything personal.
Messaging and security boundaries
Content scripts run in the page and should be treated as less trusted than the service worker. We validate every message, never pass raw HTML from the page into extension pages, and avoid exposing privileged actions to web pages through externally_connectable unless it is required. A strict content security policy and no eval or remote scripts keep the package within Manifest V3 rules.
Store policy and review
Rejections usually come from a vague single purpose, unused permissions, missing privacy disclosures, misleading listing text or code that is hard to review. We keep the code readable, avoid heavy obfuscation and document why each permission exists. When an extension is flagged after publication, we prepare a clear appeal with the exact changes made.
Performance on every page
A content script that runs on every page adds weight to every page the user opens. We inject only where needed, load heavy code lazily, use Shadow DOM so injected UI does not clash with site styles and keep bundles small. The result is an extension that users do not notice slowing them down.
Skills and tools our Chrome extension developers use
Extension platform and APIs
- Manifest V3
- Service workers
- Content scripts
- chrome.sidePanel
- chrome.storage and alarms
- declarativeNetRequest
- Offscreen documents
- chrome.identity (OAuth)
Languages and frameworks
- TypeScript
- React
- Svelte
- Vue
- Tailwind CSS
- Shadow DOM
Build and tooling
- WXT
- Plasmo
- Vite with CRXJS
- webpack
- ESLint
- GitHub Actions
Testing and release
- Vitest and Jest
- Playwright
- Puppeteer
- Chrome Web Store API
- Microsoft Edge Add-ons
- Sentry
Why Dware
Why hire Chrome extension developers from Dware
Specialists in Manifest V3
Our developers build for the platform as it works today, not as old tutorials describe it. That means fewer lost events, fewer rejections and less rework later.
Store work included
Listing, screenshots, privacy forms, permission justifications and review replies are part of the job. You do not have to learn Chrome Web Store policy yourself.
Senior review on every change
A second senior engineer reviews every pull request for bugs, security and policy risks before it is merged.
You own everything
Code lives in your repository and the extension is published from your developer account. All code and IP are yours, and we sign an NDA on request.
Fast start, low risk
We match you with a developer within 48 hours and every engagement starts with a two-week risk-free trial.
Ways to work with us
Ways to hire Chrome extension developers
Hire one developer, add a whole team, or hand us a fixed-scope project. Tell us what you need and we'll send a free, fixed quote, usually within one business day.
Dedicated developer
Most popularA senior engineer who works only on your product, full-time or part-time.
- Joins your Slack, standups and Git
- Same developer every day
- Scale up or down monthly
Team extension
Two or more developers, plus QA or a tech lead, added to your team.
- Matched to your stack and time zone
- One point of contact
- Add or remove people any month
Fixed-scope project
A clear scope, timeline and fixed quote. Ideal for MVPs, apps and fixes.
- Free, fixed quote before we start
- Milestones you approve
- Support after launch
FAQ
Hire Chrome extension developers: frequently asked questions
How much does it cost to hire Chrome extension developers?
Cost depends on what the extension does. A popup that saves links is very different from an extension with content scripts on many sites, user accounts, a backend and AI features. The number of target sites, browsers, integrations and your deadline all matter, as does whether you need one developer or a small team. After a short call we send a free, fixed quote with a clear scope, so you know the total before work starts.
How long does it take to build and publish a Chrome extension?
A focused extension usually has a first installable build in one to two weeks and can be ready for the store in three to six weeks. Larger products with a backend, payments or many target sites take longer. Chrome Web Store review often takes a few days, but extensions with broad host permissions or sensitive data can take longer, so we plan the submission into the schedule.
What is Manifest V3 and do I need it?
Manifest V3 is the current extension platform in Chrome. Chrome has phased out Manifest V2, so any extension that wants to run in Chrome today needs to be on Manifest V3. The biggest changes are the service worker background, the ban on remotely hosted code and declarativeNetRequest for network rules. If you still have a Manifest V2 extension, we can migrate it and keep your existing users.
Why was my extension rejected by the Chrome Web Store?
Common reasons are asking for permissions the extension does not use, a purpose that is too broad, missing or inaccurate privacy disclosures, listing text that does not match what the extension does, or code that is obfuscated or loads remote scripts. The rejection email includes a violation reference that points to the policy. We read it, check your code and listing, fix the real cause and resubmit with clear notes.
Will my Chrome extension also work in Edge, Brave and Opera?
Mostly yes. These browsers are built on Chromium and support the same extension APIs. Brave and Opera users can install directly from the Chrome Web Store, and for Edge we publish the same package to Microsoft Edge Add-ons. A few APIs differ slightly, so we test each browser before release. Firefox and Safari need more work, and we cover those on our Firefox and Safari pages.
Can you add AI features without exposing our API keys?
Yes. Anything shipped in an extension can be read by anyone who installs it, so API keys must never be in the package. We route AI requests through your own backend, which holds the keys, checks the user and applies rate limits. The extension only sends the page text or selection the user chose to share, and we disclose this clearly in the privacy practices form.
Who owns the extension and the Chrome Web Store listing?
You do. We publish from your own Chrome Web Store developer account, or help you create one and add us as group publishers. Source code lives in your repository from the first commit, and all code and IP belong to you. If we part ways, nothing needs to be transferred because it was always yours.
Can you build an internal extension just for our team?
Yes. Internal tools are a common use. We can publish the extension as private to your Google Workspace domain or as unlisted, and your IT admin can force-install it for staff with Chrome policies. Internal extensions still need good permission design, because they often touch customer data in your CRM or support tools.
What happens after the extension is live?
Chrome ships a new stable version about every four weeks and the websites your extension touches change without warning. We offer post-launch support to monitor errors, fix broken selectors, test against upcoming Chrome versions and roll out updates in stages. You can scale support up or down monthly as your needs change.
More developers you can hire
Hire Firefox extension developers
Hire Firefox extension developers to build or port add-ons, pass AMO signing and review, and ship to desktop and Android. Book a free consultation today.
Learn moreHire Safari extension developers
Hire Safari extension developers to build Safari Web Extensions for Mac, iPhone and iPad, packaged in Xcode and shipped on the App Store. Get a free quote.
Learn moreHire React developers
Hire React developers for SPAs, dashboards and design systems. Senior, tested in TypeScript and React Testing Library. Tell us about your project for a free quote.
Learn moreHire AI developers
Hire AI developers to build LLM apps, chatbots, RAG over your data and AI agents with OpenAI, Claude and Gemini. Senior engineers. Get a free, fixed quote.
Learn moreTell us about your Chrome extension
Share your idea, your existing extension or your rejection email. We will reply with a clear plan and a free, fixed quote, and can match you with a senior Chrome extension developer within 48 hours.