Chrome extension development for the tabs your team already works in

What is Chrome extension development, and when does a business need it?

Chrome extension development is building a small program that installs into the browser and adds features to web pages or to Chrome itself. A business needs one when the work happens inside websites it does not control and switching tabs is costing real time.

Picture a recruiter who opens forty candidate profiles a day on a job portal and retypes each one into an applicant tracking system. Or a support agent who reads a customer’s email in Gmail and then searches for the same customer in a separate billing tool. In both cases the website is not yours, so you cannot add a button to it. An extension can. It can read what is on the page (with permission), show your own panel beside it, and send the useful parts to your system in one click.

Extensions are also a product channel. Many SaaS tools ship a companion extension so users can clip, save or look things up without leaving the page they are on. For some products the extension becomes the most used part of the whole service.

What an extension is not: a replacement for a proper web app. If the work does not depend on a third-party page, a normal web application is simpler to build, easier to update and needs no store approval. We will tell you that on the first call if it applies.

Manifest V3: the rules every Chrome extension must follow in 2026

Every Chrome extension built today must use Manifest V3. Chrome’s official deprecation timeline states that Chrome 138 disabled Manifest V2 extensions for all users, and that all remaining Manifest V2 extensions were removed from the Chrome Web Store on 31 August 2026.

Manifest V3 changes three things that matter to a business owner. First, the background page is replaced by a service worker, which Chrome shuts down when idle. According to Chrome’s documentation, a worker is terminated after 30 seconds of inactivity, when a single event or API call runs longer than 5 minutes, or when a fetch response takes over 30 seconds. Anything that needs to survive must be saved to storage, not kept in a variable.

Second, all executable code must ship inside the extension package. Chrome’s guidance on remotely hosted code says extensions must bundle all code they use; loading a script from your server at runtime is not allowed. Fetching data such as JSON settings or CSS is still fine. Practically, that means a bug fix to extension logic needs a new store version, while a change to prices, rules or feature flags can come from your API.

Third, network request blocking moved to a declarative rules system. Most workflow and SaaS extensions never touch it, but ad-blocking or filtering ideas need a different design from what older tutorials show.

If you are also moving an old web front end onto a current framework, the same “rebuild without stopping the business” thinking appears on our AngularJS to Angular migration page.

The parts of a Chrome extension, in plain language

Most business extensions are built from five parts. Knowing them helps you read a quote, because each part is a line item with its own effort.

On the server side, most extensions need an API for login, saving data and admin. We build that in Node.js or Python; our API development page covers the backend patterns in more depth.

Popup or side panel: which interface suits your extension?

Choose a side panel when users work alongside a page for minutes at a time; choose a popup for quick one-click actions. Chrome’s sidePanel API, available from Chrome 114, lets an extension keep a panel open next to the page, and it stays open as the user moves between tabs.

Popups close the moment the user clicks elsewhere. That suits “save this page”, “start timer” or “translate selection”. It frustrates anyone doing real work, such as comparing a candidate profile with notes, filling a CRM record while reading an email, or checking a supplier’s price against your own list. For those jobs the side panel feels like a second screen inside the browser.

Injected UI is the third option: a button or badge placed directly on the host page, such as “Add to CRM” next to a name. It is the most discoverable, but it depends on the host site’s layout, so it carries the highest maintenance cost. Many good extensions combine all three: a small injected button that opens the side panel with the record already loaded.

Whichever you pick, we design for keyboard use and screen readers, and we keep the panel fast by rendering with a light framework such as Preact or plain TypeScript rather than a heavy single-page app bundle.

Chrome extension development cost: what pushes a quote up or down

The cost of Chrome extension development depends far more on the backend, the number of host websites and the permissions involved than on the extension screens themselves. A single-site helper for your own staff is a small job; a public extension for customers with accounts and billing is a software product.

• Host websites. Each site the extension reads or modifies needs its own selectors, tests and upkeep. Three sites cost noticeably more than one.
• Backend scope. Login, team accounts, usage limits, subscriptions and an admin dashboard are a web app in their own right.
• Permissions. Access to all websites, tabs, cookies or downloads means more justification work and longer store review.
• Offline and sync. Queuing actions when the network drops and syncing later adds careful state handling in the worker.
• AI features. Summaries or classification add a server-side model call, prompt testing and cost controls.
• Browsers covered. Edge is usually a small step from Chrome; Firefox needs testing of its own background model.

As a guide, a focused internal extension starts at ₹40,000 (US$600), and a customer-facing extension with accounts and a backend starts at ₹60,000 (US$900). Full plan details are on our pricing page. Other developers’ quotes vary widely; compare how each one handles the list above rather than the headline figure.

Chrome extension development for SaaS products: login, sync and billing

A SaaS companion extension should reuse your product’s existing login and API rather than inventing its own. The extension becomes a thin client: it signs the user in, fetches what it needs and sends actions back, while the real business rules stay on your server.

For sign-in we normally use the chrome.identity API or a standard OAuth flow that opens your login page in a tab and returns a short-lived token. Tokens are kept in extension storage, refreshed quietly and never exposed to the websites the extension runs on. If your product already offers single sign-on for teams, the extension can follow the same route so admins do not manage a second set of accounts.

Billing belongs in your web app, not the extension. The extension simply asks the API what the user’s plan allows and shows or hides features. That keeps pricing changes out of store review and means one subscription covers web, extension and any future mobile app.

Sync is where a lot of extensions go wrong. Because the service worker can stop at any moment, every change is written to storage first and sent to the server with a retry queue. Conflicts are settled on the server with timestamps. Your admin panel then shows exactly what each user saved and when, which your support team will thank you for.

Still validating the product itself? Our MVP development page explains how to launch a lean version first, and SaaS SEO covers how people will find it.

Permissions and privacy: how to keep users and reviewers comfortable

Ask for the fewest permissions that make the feature work, and explain each one in the listing. Chrome Web Store documentation says broad host permissions such as access to all URLs, and sensitive permissions such as tabs, cookies or downloads, lead to more intensive review and longer waits.

In practice we plan permissions before writing code. If the extension only works on one CRM, it asks for that one domain, not every site. If a feature needs a page only when the user clicks, we use the activeTab pattern so access is temporary. Optional permissions can be requested later, at the moment a user turns on the feature that needs them, which is both kinder and easier to approve.

Privacy disclosures in the developer dashboard must match what the code does. If the extension sends page content to your server or to an AI model, the listing says so, your privacy policy says so, and the user sees it before the first send. We also avoid collecting browsing history the feature does not need; it is a liability you do not want on your server.

For extensions used by staff, your IT team can force-install and pin them through Chrome browser management, and restrict them to company accounts. That removes a lot of the “please install this” friction inside an organisation.

How long does Chrome Web Store review take, and why do extensions get rejected?

Chrome’s documentation says most extensions are reviewed within a few days, though some take up to a few weeks, and suggests contacting support if nothing has happened after three weeks. The same review applies to updates, so plan release dates with that buffer.

Rejections usually come from a short list of causes, and nearly all of them are avoidable with preparation:

• Permissions that are broader than the described feature, or not justified in the dashboard.
• Obfuscated code, which Chrome’s documentation states is not allowed; minified code is permitted but slows review.
• A listing whose description, screenshots or name do not match what the extension actually does.
• Missing or inaccurate privacy disclosures when user data leaves the browser.
• Code or scripts loaded from a server at runtime, which Manifest V3 forbids.
• Keyword-stuffed titles or descriptions that read like spam.

We write the listing, the permission justifications and the privacy answers alongside the code, so review questions have ready answers. If a rejection arrives anyway, we read the reason, fix the specific issue and resubmit, and this work is covered inside your free maintenance window. The same discipline helps on mobile stores, as our Google Play rejection guide shows.

Public, unlisted or private: publishing a Chrome extension

Publish publicly when anyone should find and install the extension; choose unlisted when only people with the link should get it; and use private or managed deployment when it is an internal tool for your own staff.

The Chrome Web Store charges a one-time registration fee for a developer account, and its documentation warns that the account email cannot be changed after the account is created. We therefore ask you to create the account with a shared business mailbox you control, then add us as needed. The extension and its listing stay yours even if you part ways with us.

For internal tools, many organisations skip the public store entirely and deploy through Chrome browser management, pinning the extension for everyone in a group. Updates still go through a controlled channel, and staff never have to hunt for an install link.

A public listing brings its own small marketing job: a clear name, a one-line summary, honest screenshots and a short video. Search inside the store works on the name and description, so write for the words users type, not clever branding. We draft all of this with you and keep it truthful, because a listing that oversells is a listing that gets flagged.

Can one Chrome extension also work in Edge and Firefox?

Yes, usually from a single codebase. Microsoft Edge is built on Chromium, so a Chrome extension typically needs little more than a new store listing; Microsoft’s documentation states there is no registration fee for submitting extensions to the Edge Add-ons program.

Firefox takes a little more care. Mozilla’s Extension Workshop says Manifest V3 became generally available in Firefox 109, but Firefox keeps event-driven background scripts where Chrome uses a service worker. Firefox also supports the chrome.* namespace alongside its own promise-based browser.* APIs. We handle those differences in a thin adapter and a build step that outputs a package per browser.

Before paying for three browsers, check where your users actually are. For an internal tool at a company that standardised on Chrome, a Firefox build is wasted money. For a public productivity tool, Edge is cheap reach, and Firefox matters if your audience skews towards developers or privacy-minded users.

Safari is a different story: it requires packaging through Xcode and an Apple developer account, which costs US$99 a year. We take Safari on only when the audience clearly justifies it, and we say so in the quote.

Tech stack for Chrome extension development

Our default stack for Chrome extension development is TypeScript, a modern bundler with extension support, a light UI layer for the popup and side panel, and a Node.js or Python backend on the cloud account you own.

TypeScript earns its place because message passing between the worker, content scripts and panel is where silent bugs hide; typed message contracts catch them at build time. For the UI we keep bundles small, since a side panel that takes two seconds to open feels broken. React is fine when your web app already uses it and you want to share components; otherwise Preact or plain TypeScript does the job with less weight.

On the backend we reuse your existing API when there is one. When there is not, a small REST or GraphQL service with authentication, a Postgres database and a simple admin screen covers most needs. Our GraphQL API page explains when that style is worth it.

Red flags when hiring for Chrome extension development

The biggest warning sign is a developer who wants to publish the extension under their own store account. Whoever owns the account controls updates, so insist that it is registered to your business from day one.

• A quote that says nothing about Manifest V3, service workers or bundled code.
• A request for access to all websites when the feature only needs one domain.
• API keys for AI or third-party services placed inside the extension, where anyone can extract them.
• No plan for what happens when the host website changes its layout.
• Scraping features that ignore the host site’s terms or collect data users never agreed to share.
• No test copies of the host pages, so nobody notices breakage until users do.
• Delivery as a zip file only, without the source repository and build instructions.

If you are comparing a solo freelancer with a larger team, our company vs freelancer comparison lays out the trade-offs, and questions to ask a developer gives you a ready checklist.

How long does Chrome extension development take?

A focused workflow extension typically takes 2–4 weeks with our team, and a customer-facing extension with a backend takes 6–12 weeks, plus store review time on top.

The first week goes to a spike: we load the host pages, confirm we can read the elements we need, and test the login flow. This is where surprises surface, such as a CRM that renders inside an iframe or a portal that changes class names on every deploy. Settling those early saves weeks later.

Weeks two and three build the core loop: the panel, the capture or action, and the API call. You get an unpacked build to install on your own machine every week, so feedback comes from real use, not screenshots. Backend-heavy projects then spend several weeks on accounts, admin and billing.

The last stretch is polish and submission: listing copy, screenshots, privacy answers and the first release. Once a published extension has more than 10,000 weekly active users, Chrome Web Store documentation lets you roll an update out to a percentage of them first, which limits the damage if something slips through. For a broader view of scheduling software work, see how long it takes to build an app.

AI-powered Chrome extension development: doing it safely

An AI extension should send page content to your own server, which calls the model and returns the answer. Putting a model API key inside the extension is a mistake, because anyone can unpack an extension and read it.

Useful business patterns include summarising a long email thread in the side panel, drafting a reply in your brand’s tone, extracting invoice fields from a supplier portal, or scoring a lead from a profile page against your ideal customer rules. Each one works best when the user triggers it, sees what will be sent, and can edit the result before it goes anywhere.

Cost control lives on the server too: per-user limits, caching repeated requests, and choosing a smaller model for simple classification. We log prompts and outputs (with personal data trimmed) so you can see how the feature behaves in real use and adjust it.

If the AI part is the heart of the project rather than a feature, our AI agent development and RAG chatbot pages explain the server-side work in more depth. AI features inside an extension start from ₹40,000 on top of the extension itself, depending on scope.

Chrome extension development across India

We take on Chrome extension development for businesses anywhere in India, entirely over video calls, WhatsApp and shared test builds, in English or Hindi. There is no office to visit; you install weekly builds on your own laptop and tell us what feels wrong.

Product startups in Bengaluru, Pune and Hyderabad usually want a companion extension for their SaaS. Recruitment and staffing teams in Noida and Chandigarh ask for candidate capture from job portals into their ATS. Marketplace sellers in Surat and Jaipur want order and listing helpers for seller dashboards. Back-office and accounting teams in Ahmedabad, Kolkata and Coimbatore want data-entry shortcuts between portals and their own software.

Indian clients receive quotes in rupees and pay by UPI or bank transfer, with GST invoice details settled at quote stage. Hindi labels or a bilingual panel are simple to add when your staff prefer them; you approve the wording.

Worked example: a lead-capture extension for a B2B sales team

This scenario is hypothetical and exists only to show how we would scope Chrome extension development. Imagine a twelve-person B2B sales team in Pune that researches prospects on professional networking sites and company websites, then types details into a CRM by hand.

The brief: a side panel that, when a salesperson clicks “Capture”, reads the visible name, role and company, lets them correct it, checks the CRM for duplicates and creates the lead with a note. Managers want a weekly count per person.

The plan would limit host permissions to the specific sites used, trigger reading only on click, and send data to a small backend that talks to the CRM’s API. Staff sign in with their CRM credentials through OAuth; the extension is force-installed through the company’s Chrome management and published as private. Selectors for each site live in one module with saved test pages.

Because it is an internal tool with one CRM integration, the quote would start from ₹40,000, with separate lines for the duplicate check and the manager report. A realistic schedule is three to four weeks, with salespeople testing a build in week two. Nothing here describes a real client or a promised outcome.

Chrome extension checklist: what you should own at handover

At handover you should hold the source code, the store account, the backend and every credential, with enough documentation that another developer could ship the next version without calling us.

• The Git repository in your account, with full history and a README that explains build, test and packaging.
• The Chrome Web Store developer account and listing registered to your business email.
• Edge and Firefox listings, if built, under your own publisher accounts.
• Backend hosting, database and domain in your cloud account, with an environment template free of secrets.
• A permissions sheet explaining why each permission exists, ready for future reviews.
• The selector map and saved test pages for every host website.
• Privacy policy text matching what the extension collects.

After launch you get 2 months of free maintenance covering fixes and host-site layout changes; ongoing care then starts at ₹8,000/mo (US$120/mo). Our terms explain how deliverables and payments work. For a similar ownership checklist on mobile, see app maintenance.