What Is a Web Browser Extension? A Developer's Guide

What Is a Web Browser Extension?

A browser extension is a small, sandboxed program installed into a browser that modifies or augments the browser's behavior on pages a user visits — it does not run as a standalone process and has no existence outside the browser that hosts it. It's not an app; it's a set of privileged scripts and assets the browser loads, isolates, and grants scoped access to based on a manifest declaration.

The terminology gets muddled in casual use. "Plugin" historically referred to binary modules like Flash or Java applets that plugged into the browser's rendering pipeline directly — largely dead technology now. "Add-on" is Firefox's branding for the same concept as an extension. In 2026, plugins are obsolete, add-ons and extensions are the same architecture under different vendor naming, and everything ships through the same manifest-driven model regardless of what a store front-end calls it.

Understanding what technically counts as a browser extension matters because it defines the boundary of what you can build with one — and where you can't.

How a Browser Extension Is Built: The Core Pieces

Browser extension architecture splits work across isolated execution contexts, each with a different privilege level and lifecycle.

The manifest.json file is the entry point — a declarative config that lists permissions, points to scripts, and tells the browser what the extension is allowed to touch before a single line of code runs. Nothing executes that isn't declared here first.

The background service worker is the extension's persistent (but event-driven, not always-running) logic layer. It handles state, listens for browser events, and coordinates network requests. It has no direct DOM access to any page.

Content scripts run in the context of a web page — injected into the DOM, able to read and modify it, but executing in an "isolated world" that shares the DOM with the page's own JavaScript without sharing variables or functions. This isolation stops a hostile page script from reaching into the extension's internals, and vice versa.

The popup/UI is the small HTML page that appears when a user clicks the extension's toolbar icon — a separate context again, typically talking to the background worker via message passing rather than touching pages directly.

The content script vs background script split exists because a browser has to assume every web page is potentially hostile. Giving full extension privileges to code running inside an untrusted page would defeat the entire security model, so the browser enforces a messaging boundary between the two.

What Permissions Actually Let an Extension Do

An extension's capabilities are gated entirely by what it declares — and what a user or admin approves. Host permissions specify which origins (e.g., https://example.com/* or all URLs) the extension can inject scripts into or read network activity from. Without a matching host permission, a content script simply won't run there. The activeTab permission is narrower and more user-trust-friendly: it grants temporary access to the current tab only when the user explicitly invokes the extension, rather than standing, always-on access to every site.

So an extension can access only the origins it was granted, only while installed in that one browser profile, and only for the user who installed it. It can read and rewrite DOM content, intercept and modify some network requests, store local data, and communicate with a backend it controls — but always scoped to a single, live, logged-in human session. This model was never designed for unattended, server-side operation across thousands of sessions at once.

Manifest V3: Why It Matters Now

Manifest V3 is no longer "the new version" — it's the only supported platform. Manifest V2 has been fully retired as of 2026, and extensions still packaged against it simply won't load in current Chromium or Firefox builds. The core technical shifts: background pages became service workers that can be terminated and restarted by the browser instead of running indefinitely, and broad request-blocking APIs were replaced by declarativeNetRequest, which requires rules to be declared upfront rather than allowing arbitrary runtime interception of every network call. For the full technical rundown, Manifest V2 vs V3: What Actually Dies in August 2026 covers it well. The practical takeaway: plan exclusively around V3.

Browser Extension vs. Headless Browser API: Picking the Right Tool

This is where the systems question turns into an engineering decision. A browser extension runs inside one specific user's live browser — it needs that human's installed browser, their logged-in session, their machine's resources, and it operates one install at a time. It's superb for productivity tools, in-page UX modification, or anything where the point is augmenting a real person's browsing session.

It's the wrong tool the moment your goal is server-side: rendering pages at scale, generating screenshots or PDFs on demand, or extracting structured data from thousands of URLs without a human anywhere in the loop. There's no user to click "install," no persistent logged-in session to inject into, and no practical way to run one extension instance per scraping job across a fleet of servers.

That's the gap a headless browser API fills. Instead of a script embedded inside someone's browser, you get a real browser engine running server-side, controllable entirely through API calls — no manifest, no permission prompts, no content-script isolation to fight against. Browsevra exposes exactly that: programmatic rendering, screenshot and PDF generation, and structured extraction, callable from your own backend at whatever concurrency your job requires. If your task looks more like crawling and data extraction than in-browser UX, it's also worth reading What Is a Web Crawler? A Developer's Definition to see how that concept differs again from both extensions and scraping APIs.

The deciding question is simple: does the job need to run inside a specific human's already-authenticated browser session? Build an extension. Does the job need to run unattended, at scale, on your own infrastructure or schedule? Reach for a headless browser API instead of trying to bend an extension into a role it was never built for.

If you're building for the second case, check the docs to see the API surface, or compare plans on pricing against the ongoing cost of maintaining a browser extension fleet you'd otherwise have to build yourself.

Frequently Asked Questions

Is a browser extension the same thing as a plugin?

No. Plugins were binary modules like Flash or Java applets that plugged directly into a browser's rendering engine and are now obsolete. Extensions are script-based, manifest-declared programs, and "add-on" is simply Firefox's name for the same extension architecture.

Can a browser extension access every website I visit?

Only if it was granted broad host permissions covering all URLs and the user approved that scope. Otherwise access is limited to the specific origins declared in its manifest, or temporarily to the active tab via the activeTab permission when the user invokes it directly.

Why do extensions need a background script and a content script?

Because the browser treats every web page as potentially hostile and enforces an isolation boundary between page-facing code and privileged extension logic. The background service worker holds state and coordinates activity with no DOM access, while the content script runs inside the page's DOM in an isolated world, and the two communicate only through explicit message passing.

Can I use a browser extension to scrape data at scale?

Not practically. An extension runs inside one user's live, logged-in browser one install at a time, with no mechanism for running unattended across thousands of sessions on your own infrastructure — that job belongs to a server-side headless browser API instead.

Do browser extensions still work now that Manifest V2 is gone?

Extensions built on the current Manifest V3 standard work fine; Manifest V2 packages are fully retired as of 2026 and will not load in current Chromium or Firefox builds. Developers need to target V3's service workers and declarativeNetRequest model exclusively going forward.

What's the difference between a browser extension and a headless browser API?

A browser extension runs inside a specific human's live browser session and requires per-user installation, while a headless browser API runs a real browser engine on a server, controllable entirely through code with no human session required. The API model is built for automation, scraping, and generating screenshots or PDFs at whatever concurrency the job demands.