How AI Browser Extensions Actually Read Web Pages

Whenever someone asks an AI browser extension to summarize an article or answer a question about what’s on the page, two things happen that are invisible to the user: the extension has to extract the page’s text, and it has to decide what to do with it. The answers to both of those questions have direct implications for quality and privacy.

Here is a plain-language account of how it actually works.

Step 1: Getting the page’s text

A browser extension can inject a content script — a JavaScript file that runs inside the page and has access to the page’s DOM (Document Object Model), the tree of HTML elements that makes up the page.

From the DOM, the extension can read the text content of any element. Most extensions doing page summarization don’t grab everything — they specifically try to extract the main body text, filtering out navigation menus, headers, footers, cookie banners, and the other boilerplate that surrounds an article but isn’t part of it.

Some extensions do this by identifying semantic elements (the HTML <article> tag, <main>, or similar). Others use heuristics — looking at which block of text is the longest, where the most paragraph tags are concentrated, or whether a particular element has a reading-like text density. The result is rarely perfect, but it’s usually good enough to remove 80–90% of the noise.

What the extension does not do is send raw HTML to the AI. Raw HTML is full of tags, attributes, and markup that consume tokens without adding information. Most AI queries work on plain text.

Step 2: Fitting text into a context window

Every language model has a context window — a maximum number of tokens (roughly, words and word pieces) it can process in a single request. For Gemini 1.5 Flash, that window is up to one million tokens; for older or smaller models, it might be 8,000 or 32,000.

Most articles fit comfortably. A long blog post of 3,000 words is roughly 4,000 tokens — well within even a small model’s context.

Very long pages — a dense research paper, a transcript, a full-length ebook — can exceed the limit. When that happens, the extension either:

• Truncates — sends the first N tokens and ignores the rest. Simple but lossy.
• Chunks — splits the text into overlapping sections and queries each one separately, then combines the answers. More thorough but slower and costlier.
• Summarizes in stages — extracts a condensed version first, then queries the summary. Works well for “give me the key points” but loses detail.

Which approach an extension uses — and whether it tells you which — is worth knowing if you’re using it for research tasks where completeness matters.

Step 3: Sending the query

Once the extension has the page text and your question, it constructs a prompt. A typical prompt looks like:

You are a helpful assistant. Using only the content below, [user's question].

CONTENT:
[extracted page text]

This prompt goes to the AI API — Gemini, Grok, or whichever provider the extension supports.

In a BYOK (Bring Your Own Key) extension like Browsy, this request goes directly from your browser to the AI provider’s servers. The extension developer’s infrastructure is not in the path. Your page text, your question, and the AI’s answer pass through the provider you chose and nobody else.

In non-BYOK extensions, the request typically goes through the extension developer’s servers first. Their servers act as a proxy: they receive your page text and question, add their API key, forward the request to the AI provider, receive the answer, and return it to you. This is not inherently malicious — it’s how subscription products cover their API costs — but it means the extension developer’s servers are seeing your page content.

How to verify what Browsy actually sends

Browsy’s BYOK architecture makes the request path verifiable. If you want to check exactly what’s being sent:

1. Open Chrome DevTools (F12 or Ctrl+Shift+I on Windows/Linux, Cmd+Option+I on Mac).
2. Go to the Network tab.
3. Ask Browsy to summarize the current page.
4. Look for a request to generativelanguage.googleapis.com (Gemini) or api.x.ai (Grok).
5. Click the request, then the Payload or Request tab to see the request body.

You’ll see the exact text that was sent. The contents array in the Gemini API request format shows the page content and your question, and nothing else.

If you see a request going to a domain other than your AI provider’s — a company you don’t recognize, or the extension’s own domain — that’s the signal that a proxy is in the path.

What Browsy doesn’t access

Content scripts have access to the page the user is actively viewing — the tab the extension is running on. Browsy’s content script does not:

• Read other open tabs
• Access your browsing history
• Store the extracted text anywhere — it’s used for the current query and discarded
• Send the text to any server except your chosen AI provider

Extensions request permissions when installed. The permissions page in the Chrome Web Store lists what an extension can access; “Read your browsing history” and “Read and change your data on all websites” are the ones that expand access significantly. An extension that only requests “Read your data on the current tab” is narrowly scoped.

---

Understanding how page reading works is useful for evaluating any AI extension, not just Browsy. The key questions are: what is extracted, where does it go, and can you verify it? The answers to those questions are the most important privacy signal an extension can give.