How Chrome Extensions Work: A Clear Explainer (2026)

A Chrome extension is a folder of ordinary web files — HTML, CSS, JavaScript, a few icons — plus one configuration file that tells Chrome what the folder is allowed to do. That is the whole thing. There is no compiled binary, no installer, no native code. On install, Chrome unpacks that folder into a private directory and runs its JavaScript with the privileges the folder asked for and you approved.

Understanding how chrome extensions work matters even if you never write one, because the architecture is exactly what determines the answer to the question you actually care about: what can this thing see, and what can it do when I am not looking. This explainer walks through the moving parts, the permission model, and how to read a store listing once you know what the pieces mean.

The Manifest Is the Contract

Every extension has a file called manifest.json. It is the first thing Chrome reads and it acts as a contract between the extension and the browser. Nothing an extension does is possible unless the manifest declares it in advance.

The fields that matter most when you are trying to work out what an extension does:

• manifest_version — must be 3 for anything published today. Version 2 has been retired.
• name, version, description — what you see on the store listing and the extensions page.
• permissions — the browser capabilities requested, such as clipboard writing, storage, or access to tab metadata.
• host_permissions — which websites the extension can read and modify. This is the field that really matters.
• background — points at the service worker script, where the background logic lives.
• content_scripts — which scripts get injected into which pages, and when.
• action — the toolbar button and the popup it opens.
• commands — keyboard shortcuts the extension wants to register.

Because the manifest is declarative, Chrome can enforce it. An extension that never declared host permissions physically cannot read a page — the API calls simply fail. This is the foundation of how chrome extensions work safely: capability is granted up front and checked by the browser, not requested politely at runtime.

The Four Moving Parts

Most extensions are built from some combination of four pieces. Small ones use two.

1. The service worker (background logic). A JavaScript file that runs outside any web page, in its own process. It listens for events — a keyboard command, a toolbar click, a tab finishing loading, an alarm firing — and reacts. It has no user interface and no direct access to page content. Under Manifest V3 it is event-driven, which means Chrome starts it when something happens and shuts it down when it has been idle. That is why extensions cannot simply run a loop forever in the background any more.

2. Content scripts. JavaScript injected directly into web pages. This is the only part of an extension that can touch what is on screen — reading text, changing styles, adding buttons, watching for clicks. Content scripts are why an SEO tool can inspect the headings on a page and why a password manager can find the login form.

3. Extension pages. Ordinary HTML pages that Chrome renders inside the browser UI: the popup that opens when you click the toolbar icon, the options page, sometimes a side panel or a full tab page. They are regular web pages with extra privileges.

4. The Chrome extension APIs. A set of JavaScript interfaces exposed only to extensions, namespaced under chrome. Storage, tabs, bookmarks, downloads, notifications, keyboard commands, context menus, and dozens more. Each one is gated behind a permission.

A large extension uses all four. A one-keystroke utility may use only a service worker, one API, and a single permission — which is a large part of why small extensions are easier to trust.

Content Scripts and the Isolated World

The content script model is the part people most often misunderstand, and it is worth getting right.

When Chrome injects a content script into a page, that script gets full access to the page DOM. It can read every element, every piece of text, every form value. It runs in the same process as the page.

But it runs in what Chrome calls an isolated world. The content script and the page each get their own JavaScript environment. They share the DOM, but not variables, not functions, not prototypes. A page cannot detect or tamper with an extension script by overwriting a global. An extension script cannot read a variable the page is holding in memory.

Two practical consequences:

• Isolation protects both sides. A malicious page cannot hijack your extensions. A buggy extension cannot break a page by redefining something globally.
• Sharing data requires messaging. Content scripts talk to the service worker by passing messages, because they are in different processes with different privileges. The service worker can call the extension APIs; the content script mostly cannot.

That message-passing boundary is a design constraint, and it is also the reason a well-scoped extension can be audited: the places where page data can leave the page are few and explicit.

Permissions: What the Warnings Actually Mean

When you install an extension, Chrome shows a plain-language summary of what the manifest requested. The wording is vague enough to be worth translating.

"Read and change all your data on all websites." The extension declared host permissions covering every site. Its content scripts run everywhere. This is the broadest thing you can grant, and it means the extension can read the contents of your email, your bank dashboard, your admin panels, and your internal tools. Sometimes this is unavoidable — an ad blocker or an on-page SEO inspector genuinely needs it. Often it is laziness on the developer part.

"Read and change your data on example.com." Host permissions scoped to specific sites. Far better. The extension is inert everywhere else.

"Read your browsing history." The history permission. Justified for a history search tool, alarming for a theme.

"Change your privacy-related settings." Deep access to proxy, cookie, and security configuration. Rare and worth questioning.

"Display notifications", "manage your downloads", "read and change your bookmarks". Narrow, specific, easy to reason about. Each maps to a single API.

No warning at all. Some permissions are considered low risk and produce no install prompt. storage for saving settings. clipboardWrite for putting text on the clipboard. activeTab, which grants temporary access to the current tab only when the user explicitly invokes the extension, and expires when they navigate away. An extension whose install screen asks for nothing scary is usually one that genuinely does very little.

The rule that follows from understanding how chrome extensions work: judge the permissions against the stated function. A one-purpose tool asking for all-sites access is the mismatch to look for. For the evaluation checklist, see safe chrome extensions 2026.

You Can Restrict Access After Installing

Most people never discover this. Open chrome://extensions, click Details on any extension, and find Site access. Three options:

• On all sites — the default for extensions that requested it.
• On specific sites — you list the domains. Everywhere else, the extension does nothing.
• On click — the extension is dormant until you click its toolbar icon, at which point it gets access to that tab only.

For any tool you invoke deliberately rather than continuously — SEO inspectors, screenshot tools, competitive research overlays — "on click" costs you one click and removes both the performance overhead and most of the exposure. This single setting is the highest-value thing most people can do with their extension list. The full management routine is in how to manage chrome extensions.

How Keyboard Shortcuts Get Bound

Extensions declare keyboard commands in the manifest, optionally with a suggested key combination. Chrome allows suggested defaults for a limited number of commands, which is why extensions with many features leave most of them unbound.

When a bound key is pressed, Chrome wakes the service worker and fires a command event. The extension does its work and the service worker goes back to sleep. There is no polling and no key logging — Chrome only ever tells the extension about the specific combinations it registered.

You can see and change every binding at chrome://extensions/shortcuts. Each command can be set to work globally at the operating system level or only when Chrome has focus. If two extensions want the same combination, the second one silently fails to register and you rebind it here.

One nuance worth knowing: Chrome reserves many of its own shortcuts and will not let an extension steal them. That is deliberate, and it is why extension shortcuts often use three-key combinations.

Manifest V3 and Why It Changed Things

Manifest V3 is the current extension platform, and the migration away from V2 is complete. Three changes did most of the work.

Persistent background pages became service workers. Previously an extension could keep a page alive indefinitely, consuming memory whether or not it was doing anything. Now background code is event-driven and Chrome terminates it when idle. Better for memory and battery; harder for developers, who must write state to storage instead of holding it in memory.

Remotely hosted code is banned. Under V2, an extension could load and execute JavaScript fetched from a server after installation, meaning the reviewed code and the running code could differ entirely. V3 requires all executable code to ship inside the package. This is the single biggest security improvement, because it means what the store reviewed is what runs.

Request blocking became declarative. Instead of inspecting every network request in JavaScript and deciding what to block, extensions register rules and Chrome enforces them. Faster and more private in principle — the extension never sees the request — but with caps on rule counts and less flexibility, which is why content blocker authors objected loudly.

If you want to see these pieces assembled into a working extension, the step-by-step build is in how to build a chrome extension.

Storage, Updates, and What Leaves Your Machine

Storage. Extensions save data through a storage API with two main areas. Local storage stays on the device and can hold a reasonable amount of data. Sync storage is much smaller, with tight per-item and total quotas, and rides along with Chrome sync to your other signed-in devices. Neither area is readable by other extensions or by web pages.

Network access. An extension can make network requests, subject to its host permissions and the content security policy that Chrome enforces on extensions. This is the crucial question when judging privacy: does the extension need to talk to a server to do its job? A tool showing competitor traffic must send the domain you are viewing somewhere. A tool that copies the current URL to your clipboard has no reason to contact anything, ever. That distinction is visible in the permissions and in the data-collection disclosure on the store listing.

Updates. Chrome checks for extension updates periodically and applies them silently. Every update goes through Chrome Web Store review, which includes automated analysis and, for some changes, human review. The residual risk is not usually malicious code slipping past review — it is ownership change. A popular, useful extension gets sold, the new owner ships an update that adds tracking or affiliate injection, and the update installs on tens of thousands of machines without anyone clicking anything. Nothing in how chrome extensions work prevents this, which is the argument for periodic audits and for preferring small, single-purpose, ideally open-source tools.

What Extensions Cannot Do

The boundaries are as informative as the capabilities.

• They cannot run on Chrome internal pages. Settings, the extensions page, the new tab page in some configurations, and the Chrome Web Store itself are off limits. This is a hard security boundary.
• They cannot read each other data. Extension storage and extension pages are isolated per extension.
• They cannot browse your filesystem. File access happens only through explicit APIs and user-initiated pickers, and reading local files requires a setting you must enable manually.
• They cannot see incognito windows unless you explicitly allow that extension in incognito mode.
• They cannot execute code fetched at runtime under Manifest V3.
• They cannot silently escalate permissions. An update that requests new permissions disables the extension until you approve the change.

That last point is a genuinely useful safety property, and it is worth noticing when it happens rather than clicking through.

A Worked Example: A One-Keystroke URL Copier

It helps to trace a real, minimal extension end to end. Consider a tool whose entire job is to copy the current tab URL when you press a keyboard shortcut.

What the manifest needs: a commands entry declaring the shortcut, a background entry pointing at a service worker, and permission to write to the clipboard. It does not need host permissions, because it never reads page content — the tab URL is available as metadata. It does not need storage, history, or bookmarks.

What happens at runtime: you press the key. Chrome wakes the service worker and fires the command event. The service worker asks Chrome for the active tab, takes its URL string, writes that string to the clipboard, and finishes. Chrome shuts the service worker down again. Elapsed time, a few milliseconds. Data leaving the machine, none — there is nothing in that flow that touches the network.

This is what the Ctrl+Shift+C extension does: one keystroke, clipboard permission only, no network calls, zero data collection. The point of tracing it is not the product — it is that once you understand how chrome extensions work, you can look at an install prompt asking for nothing but clipboard access and correctly conclude that the tool is incapable of doing anything else. The architecture makes the claim checkable.

Reading a Store Listing With This Knowledge

Everything above collapses into a five-minute evaluation you can run before installing anything.

1. Read the permission prompt against the description. Does the scope match the stated function? A currency converter needing all-sites access is a mismatch.
2. Check the data disclosure on the store listing. Developers must declare what they collect. Nothing collected is a strong signal, especially when the permissions make collection impossible anyway.
3. Check the last update date. An extension untouched for two years is running against a web that has moved.
4. Check the developer. A named person or company with a website and a privacy policy beats an anonymous account.
5. Read the one-star reviews, sorted by recent. Ownership changes and injected ads show up there first.
6. After installing, set site access to on click unless continuous operation is the point.

None of this requires reading code. It requires knowing what the pieces are, which is the entire value of understanding how chrome extensions work as a user rather than a developer.

Frequently Asked Questions

What is a Chrome extension actually made of? A zipped folder of web files — HTML, CSS, JavaScript, and images — plus a manifest file that declares what the extension is allowed to do. There is no compiled binary and no native code, which is why extensions are auditable in a way that desktop software usually is not.

Can an extension read everything I do in the browser? Only what its declared permissions allow, and only on the sites it has host access to. An extension granted access to all sites can read and modify the content of every page you open, including authenticated dashboards, which is why that specific permission deserves scrutiny.

What is a content script? JavaScript that Chrome injects into a web page so the extension can read or change what is on screen. It shares the page DOM but runs in an isolated JavaScript world, so it cannot see variables belonging to the page and the page cannot interfere with it.

What changed with Manifest V3? Background pages became event-driven service workers, remotely hosted code was banned so the reviewed code is the code that runs, and request blocking moved to a declarative rules system. Tighter security overall, with stricter limits on what content blockers can do.

Do extensions update themselves? Yes. Chrome checks for updates periodically and installs them silently in the background. Each update passes through Chrome Web Store review, but ownership of an extension can change without notification, which is the main reason to audit your list every few months.

Can an extension work without any network access? Yes. An extension that only reads the current tab and writes to the clipboard never needs to contact a server. Tools that display remote data obviously do, and the difference is visible in both the permissions and the store data disclosure.

Why do extensions not run on some pages? Chrome blocks extensions from internal pages such as settings and the extensions page, and from the Chrome Web Store itself, as a hard security boundary. Nothing you install can inject code there, by design.

Understand the Model, Then Install Deliberately

Manifest, service worker, content scripts, permissions, updates. Five concepts, and together they explain how chrome extensions work well enough to make good decisions without reading a line of source. The practical version: match permissions to function, prefer narrow tools over suites, set site access to on click where you can, and audit the list every quarter.

Small extensions are the easiest case, because there is almost nothing to reason about. Ctrl+Shift+C copies the current tab URL with one keystroke, asks for clipboard permission and nothing else, makes no network calls, and collects no data — an extension whose architecture leaves it no room to do anything you did not ask for. Install it, apply the same five-point check to everything else on your list, and your browser stays both fast and knowable.