Two Ways to Control a Web Page — Extensions vs Injected Scripts

April 2026

Browser extensions and injected scripts can both modify a webpage — but they operate in fundamentally different layers of the browser.

To understand why this distinction matters, we first need to understand what a webpage actually is at runtime.

What is the DOM?

Before comparing extensions and injected scripts, we need to understand what they are actually modifying. Without this, the difference between them looks almost identical — but it is not.

The DOM (Document Object Model) is the browser’s live representation of a webpage.

When a browser loads a page, it:

Parses the HTML file
Builds a structured tree of elements
Exposes that structure to JavaScript

At this point, the key idea is:

The browser is no longer “showing HTML” — it is maintaining a live, editable object structure.

That structure is what we call the DOM — and it becomes the shared surface that all scripts interact with.

🧠 Simple mental model

HTML = blueprint
DOM = live object version of the page
JavaScript = code that modifies the DOM

Now that this is clear, we can understand what extensions and injected scripts are actually competing over.

Two Execution Worlds

Once the DOM exists, different actors can interact with it — but not all in the same way.

The page’s own JavaScript
Browser extensions
Injected scripts

This leads to a key architectural distinction: not all code runs in the same context.

That difference in execution context is what determines power, access, and risk.

Browser Extensions

Extensions run in a separate, sandboxed environment controlled by the browser.

This means they exist “next to” the page rather than inside it.

They can:

Read and modify the DOM
Change styling and content
React to user actions

But they cannot:

Directly access page variables
Replace internal functions
Modify execution logic inside the page

So extensions operate on what the page looks like — not how it thinks.

Injected Scripts

Injected scripts work very differently.

Instead of operating from the outside, they execute inside the page’s own JavaScript context.

This means they are no longer observers — they are participants.

This allows them to:

Share the same global scope as the page
Override functions
Modify internal state
Intercept behavior before it becomes visible

Injected scripts don’t just modify the page — they change how it behaves internally.

Why This Difference Matters

At this point, the distinction becomes meaningful:

🔐 Security

Extensions are isolated by design. Injected scripts are not.

🧠 Control Level

Extensions interact with the DOM. Injected scripts interact with execution logic.

⚠️ Risk

The closer you get to execution logic, the more control — and potential misuse — becomes possible.

Interactive Example (Core Insight)

Now that the architecture is clear, the following demo shows the difference in practice.

A simple web page with internal logic — observe what each approach can actually modify.

Web Page Counter System

Counter: 0

Log: waiting for interaction...

Mode: NORMAL PAGE

What You Should Notice

As you interact with the demo, a clear pattern emerges:

The extension modifies only the visual layer of the page
The injected script modifies the underlying behavior

This is the real boundary in browser systems: presentation vs execution.

And importantly — both still appear to be “just JavaScript,” even though they operate in fundamentally different contexts.

Final Insight

Extensions decorate the DOM.  
Injected scripts rewrite the logic behind it.  

Understanding this separation is essential for understanding modern browser architecture — from ad blockers to automation tools.