A browser extension (also called a browser add-on) is a packaged software module that extends or changes the behavior of a web browser, built with HTML, CSS and JavaScript and running through a dedicated extension API that the browser exposes. Among browser technologies, extensions occupy a special position: they run with more privileges than ordinary web pages but less than native applications, and they can read or modify pages, network requests, tabs and browser interface elements on the Web.
Modern extensions in Chromium-based browsers, Firefox and Safari follow the broadly shared WebExtensions model, described by a manifest.json file. Its current generation, Manifest V3, replaced long-running background pages with event-driven service workers and restricted how extensions may block or rewrite network traffic.
How a browser extension is structured
A browser extension is a set of cooperating components declared in its manifest. Each component runs in a different context with different capabilities, and they communicate through message passing rather than shared memory.
| Component | Runs where | Typical job |
|---|---|---|
| Manifest | Read by the browser at install | Declares name, version, permissions and entry points |
| Background service worker | Extension process, event-driven | Reacts to browser events, holds central logic |
| Content script | Inside matching web pages | Reads or changes the page DOM |
| Popup and options pages | Extension origin | User interface and settings |
| Side panel or devtools page | Browser interface | Persistent tools next to the page |
Content scripts see the page’s DOM but run in an isolated world: they share the document, not the page’s JavaScript variables. This separation protects the extension from the page and the page from the extension. To act with elevated rights, a content script sends a message to the background service worker, which can call privileged APIs such as tabs, storage, downloads or declarative network rules.
Under Manifest V3, the service worker is terminated when idle, typically after about 30 seconds without events, and restarted when the next event arrives. Any state kept only in memory is lost, so extensions must persist data with the storage API or IndexedDB.
Permissions and the security model
Every capability of a browser extension is gated by a declared permission, and the browser shows the most sensitive ones to the user at installation. The permission model is the main defense against malicious or compromised extensions, which can otherwise read everything a user sees.
| Permission | What it allows | Risk level |
|---|---|---|
| storage | Save extension data locally or synced | Low |
| activeTab | Temporary access to the current tab after a user click | Low to moderate |
| scripting | Inject scripts into permitted pages | Moderate |
| declarativeNetRequest | Block or redirect requests by rules | Moderate |
| Host permission for all sites | Read and change data on every website | High |
| cookies or history | Read browsing data across sites | High |
The safest practice is the principle of least privilege: request activeTab instead of broad host permissions where possible, and use optional permissions that the user grants only when a feature needs them. Manifest V3 also forbids remotely hosted code, meaning all executable JavaScript must ship inside the reviewed package, and it applies a strict content security policy to extension pages.
Browser extensions compared with related concepts
Several technologies change what a browser can do, but they differ sharply in privileges and lifetime. The comparison below separates a browser extension from its nearest neighbors.
| Technology | Scope | Privilege level | Current status |
|---|---|---|---|
| Browser extension | Browser-wide, across sites | Elevated, permission-based | Actively supported |
| Plug-in (NPAPI) | Embedded native content | Native code, very high | Removed from major browsers |
| Bookmarklet | Current page, on click | Same as the page | Still works, limited |
| User script | Matching pages | Depends on the host extension | Runs inside an extension |
| Progressive web app | One site or app | Ordinary web origin | Actively supported |
The key distinction is that a browser extension operates across origins, which a normal page cannot do because of the same-origin policy. Plug-ins ran native code and were removed for security reasons, whereas extensions remain inside the browser sandbox.
Typical uses and practical choices
Browser extensions serve both consumers and organizations, and each category relies on a different subset of the extension API. Choosing the narrowest API for the job reduces review friction, performance cost and risk.
| Category | Key API or feature | Practical note |
|---|---|---|
| Content blocking | declarativeNetRequest rules | Rule limits apply under Manifest V3 |
| Password managers | Content scripts and native messaging | Need broad host access to fill forms |
| Developer tools | devtools pages and debugger access | Often used only in development profiles |
| Accessibility aids | Content scripts and styles | Change contrast, fonts or reading order |
| Enterprise controls | Managed storage and policies | Installed and configured by administrators |
Distribution normally runs through a browser-specific store with automated and manual review. Organizations can also force-install extensions through managed browser policies, which is common for security agents and single sign-on helpers.
Risks, limitations and common mistakes
Because a browser extension can see sensitive data, its risks concern privacy, performance and supply chain more than functionality.
- Ownership changes: a popular extension may be sold, and a later update can add tracking or injected advertising.
- Excessive permissions: requesting access to all sites for a feature that needs one domain erodes user trust.
- Performance cost: content scripts injected into every page add parsing and execution time to each load.
- Lost state: relying on global variables in a Manifest V3 service worker fails when the worker is shut down.
- Testing distortions: extensions in a developer’s profile can alter page behavior and skew performance measurements, so testing belongs in a clean profile.
Teams that build sites should remember that users may run any extension, so page scripts must tolerate injected elements and modified styles without breaking.
In everyday language
A browser extension is a small add-on that gives your browser a new skill. It might block advertisements, fill in saved passwords or translate a page. You install it once, and it works on many websites.
Before it can act, the extension must ask for permission. Think of it like a house key. A key to one room is safe to hand out. A key to the whole house deserves careful thought, so check what an extension asks for before you install it.
Seen in the real world
A company with 400 employees wants every staff browser to warn users before they enter corporate credentials on unknown sites. The IT team builds a small internal browser extension with a content script that watches password fields and a background service worker that checks the page domain against an approved list.
The extension requests host access only for login-related pages and stores its allowlist through managed storage, so administrators can update it centrally. It is force-installed through browser policy on all company devices. After rollout, suspicious login pages trigger a clear warning, and the security team receives far fewer reports of stolen passwords. Because the code ships inside the package and follows Manifest V3 rules, browser updates do not break it.