Gmail Extensions: Complete Guide to Custom Add-ons in 2026

Gmail extensions are small applications that add features and panels directly inside Gmail, so a user can act on an email without switching to another tool. In 2026 the supported, future-proof way to build one is a Gmail add-on made with Google Apps Script and the CardService UI framework, distributed through the Google Workspace Marketplace. The older idea of a browser-based Gmail plugin still exists as a Chrome extension, but that is a different mechanism with different limits. This guide explains what each option actually is, how an add-on works under the hood, the five jobs companies most often build them for, and how to decide between an off-the-shelf tool and a custom build.

What are Gmail extensions?

A Gmail add-on is software that runs inside Gmail and adds a contextual panel, a button, or an automated action to the mail experience. When someone opens a message, the add-on can read selected fields, show a sidebar (for example a customer record or a thread summary), and write back, such as drafting a reply or logging the email to a CRM.

Google's official platform for this is the Gmail add-on, part of Google Workspace add-ons. An add-on is built with Apps Script (Google's hosted JavaScript runtime) and rendered with CardService, a declarative UI toolkit. Because the code runs on Google's servers and the interface is defined as cards rather than raw HTML, the same add-on works in Gmail on the web and in the official Gmail mobile apps without a separate build for each.

Companies in the US, UK, Germany, and Australia adopt add-ons mostly to cut the constant switching between Gmail and other systems. Instead of copying an address into a separate CRM tab, the data moves to where the work already happens, which is the inbox.

Gmail add-ons vs Chrome extensions vs Gmail plugins

These three terms get used as if they mean the same thing. They do not, and the difference decides what you can build and where it runs.

A Gmail add-on is the Google-sanctioned path. It is reviewed by Google, governed by OAuth scopes, and runs identically across devices. A Chrome extension manipulates the Gmail web page inside the browser, which gives more visual freedom but breaks on mobile, can shatter when Gmail's HTML changes, and never sees an admin approval workflow. "Gmail plugin" is not an official product name at all; people use it loosely for either of the above or for a connected third-party service. Whether you call it a Gmail addon, an add-on, or a plugin, ask the vendor which mechanism they actually mean before you commit.

How do Gmail add-ons work?

A Gmail add-on has three moving parts: the Apps Script project that holds your code, a manifest that declares what the add-on does and which permissions it needs, and the CardService calls that build the UI.

The manifest (an appsscript.json file) lists trigger functions, the OAuth scopes the add-on requests, and contextual triggers that tell Gmail when to show your interface. There are two trigger styles worth knowing. A homepage trigger shows your add-on when Gmail opens, before any message is selected, which is useful for a dashboard or a search box. A contextual trigger fires when a user opens an email that matches a rule, passing an event object with message metadata so you can render a card tied to that specific message.

A minimal contextual handler looks like this:

function onGmailMessageOpen(e) {
  const messageId = e.gmail.messageId;
  const accessToken = e.gmail.accessToken;
  GmailApp.setCurrentMessageAccessToken(accessToken);
  const subject = GmailApp.getMessageById(messageId).getSubject();

  const card = CardService.newCardBuilder()
    .setHeader(CardService.newCardHeader().setTitle("Email summary"))
    .addSection(
      CardService.newCardSection().addWidget(
        CardService.newTextParagraph().setText("Subject: " + subject)
      )
    )
    .build();

  return [card];
}

The access token in the event is scoped to the open message only, which is the platform nudging you toward least privilege. You ask for the narrow per-message scope rather than full mailbox access unless the feature genuinely needs more. Buttons on a card call back into your script through actions, so a "Log to CRM" button runs another function, does its work, and returns an updated card. That request, render, act, and return cycle is the whole programming model.

Top 5 business use cases for Gmail add-ons

Most custom builds fall into a handful of patterns. These are the five we are asked for most:

1. CRM sync. Log an email to Salesforce, HubSpot, or Dynamics, and pull the matching contact or deal into a sidebar, without leaving the inbox. This is the single most common request and the clearest time saver for sales teams. Our CRM integration work usually starts right here.
2. AI reply drafting. Summarise a long thread and draft a context-aware response with an LLM, so the user edits a starting point instead of writing from a blank box.
3. Document signing and generation. Turn an email and its attachments into a contract or an e-signature request. When the workflow touches Google Docs, this pairs naturally with Google Docs add-on development for templating and merge fields.
4. Internal tooling. Approve an expense, open a support ticket, or trigger a deployment from a button sitting inside the email that asked for it.
5. Compliance archiving. Capture messages to a regulated store with the correct metadata, which matters for finance and legal teams under records-keeping rules in the UK and the EU.

Each of these is a Gmail automation problem at heart: take a manual step a person repeats dozens of times a day and let the add-on do it in one click. The same pattern also covers lighter Gmail customization, like color-coded labels or a quick-template picker, when a team wants polish rather than a full integration.

Google Workspace Marketplace vs custom Gmail add-on development

The Workspace Marketplace lists thousands of ready-made add-ons, and plenty of jobs are solved well by one that already exists. Check there first. Off-the-shelf wins when your need is common (a calendar scheduler, a generic email tracker, a mail-merge tool), your budget is small, and you can accept the vendor's data handling and product roadmap.

A custom Gmail add-on wins when:

• Your workflow is specific to your business and no generic tool fits the way your team actually works.
• You need to connect to an internal system or a private API the public add-ons cannot reach.
• Data residency or a security review rules out sending mail content to a third-party vendor, a frequent blocker for German and UK enterprises under GDPR.
• You want to own the code, the release schedule, and the support path rather than wait on someone else's backlog.

A rough rule: if an off-the-shelf add-on covers 80% of the need and the missing 20% is cosmetic, buy it. If the missing piece is the actual reason you want the tool, build it. Our Google Workspace add-on development team is usually brought in at exactly that line, the point where a stock add-on stops short of the real workflow.

How to build a custom Gmail add-on

A production build follows a predictable sequence. Here is the path from idea to a listed add-on:

1. Design the cards and scopes. Sketch the panels users will see and list the minimum OAuth scopes each action needs. Scope discipline here saves you a painful security review later.
2. Set up the Apps Script project. Create the script, add the appsscript.json manifest, and define your contextual and homepage triggers and the functions they call.
3. Build the UI with CardService. Assemble headers, sections, buttons, and inputs as cards. Keep each interaction short and single-purpose, because a card is a focused panel, not a full web page.
4. Wire up data and APIs. Call your backend or third-party services with UrlFetchApp. When the add-on talks to outside systems, a proper API integration layer handles authentication, retries, and rate limits cleanly instead of scattering raw fetch calls through the script.
5. Test across web and mobile. Run the add-on in Gmail on the web and on the Gmail Android and iOS apps. Cards render on all three, but interactions and limits differ, so test the real devices you intend to support.
6. Submit to the Marketplace. Configure the OAuth consent screen, complete Google's verification (mandatory once you request sensitive or restricted scopes), and publish either publicly or privately to your own domain. Restricted-scope apps may also need an independent security assessment, which can add weeks, so plan the timeline around it.

A simple internal add-on can be working in days. A public, Marketplace-listed product with restricted scopes and a security assessment typically runs several weeks once review time is included.

Security, privacy, and OAuth scopes

Gmail add-ons are governed by OAuth scopes, the permissions a user grants at install. Scopes range from a narrow per-message token (read just the open email) up to full mailbox read and modify access. The rule is least privilege: request the narrowest scope that makes the feature work, because broad scopes trigger Google's stricter verification and worry the IT reviewers who sign off on installs.

Data handling is where deals are won or lost in regulated markets. Under GDPR, a German or UK customer will ask where message content goes, whether it leaves the EU, and how long you keep it. If your add-on processes protected health information for a US healthcare client, HIPAA obligations apply wherever that data lands and usually require a business associate agreement. Designing the add-on to keep data inside Google's infrastructure, or inside an approved region, removes the most common objection before it is raised.

Enterprise sign-in is the other half of the trust story. If you also build on the Microsoft side, the same identity discipline applies there; our guide to Microsoft SSO with Azure AD for Office add-ins walks through the equivalent enterprise login pattern and is a useful companion read for any team standardising on single sign-on.

When should you hire a Gmail add-on developer?

Bring in a developer when the add-on has to touch a real business system, when restricted OAuth scopes put you in front of Google's security review, or when an inbox workflow is costing your team measurable hours every week. Apps Script lowers the barrier to a first prototype, which is genuinely useful, but production concerns (scope minimisation, error handling, Marketplace verification, mobile testing, and a codebase someone can maintain a year from now) are where most internal attempts stall.

We have shipped 250+ projects across Microsoft 365 and Google Workspace over 5+ years, for 100+ clients, with a 98% client satisfaction rate. If a custom inbox tool is on your roadmap, our Gmail add-on development team can scope it, build it, and get it through Marketplace review.

Frequently asked questions

What's the difference between a Gmail extension and a Gmail add-on?

In everyday speech they mean the same thing. Precisely, a Gmail add-on is Google's official product, built with Apps Script and listed on the Workspace Marketplace. "Extension" is the casual word people reach for, often borrowed from browser extensions, which are a separate Chrome-based mechanism that works differently.

Are Gmail add-ons free?

Many Marketplace add-ons are free or freemium, and Apps Script itself costs nothing to use. A custom add-on is a one-off build cost, plus any hosting or third-party API fees the features rely on. Google does not charge users to install or run an add-on.

Can a Gmail add-on read my emails?

Only within the OAuth scopes you grant at install. A well-built add-on requests a per-message token that reads just the email you have open. Broader access such as full mailbox read is possible but must be requested explicitly and passes Google's verification, so users see exactly what they approve.

How long does it take to build a custom Gmail add-on?

A focused internal add-on can be ready in a few days to two weeks. A public, Marketplace-listed add-on with restricted scopes takes several weeks, mostly because Google's verification and any required security assessment add review time on top of the development work itself.

Do Gmail add-ons work on the Gmail mobile app?

Yes. Because Workspace add-ons are defined with CardService and run on Google's servers, the same add-on appears in the official Gmail apps on Android and iOS, not just the web. Behaviour can vary slightly per platform, so test on the devices you support.

Build a custom Gmail add-on

We design and ship custom Gmail add-on development for teams that have outgrown off-the-shelf inbox tools. If you know the workflow you want, build a custom Gmail add-on with a team that has taken add-ons through Marketplace review before.

Not sure whether to buy or build? Discuss your project on a free scoping call and we will give you a straight answer on the fastest route to a working tool.