How AI Browser Assistants Handle Long Web Pages: Chunking, Context Windows, and What Gets Summarized
When you ask a browser AI to summarize a long article, something has to decide which parts of the page to send to the model. Here's how that works, and what it means for accuracy.
Key takeaways
- Every AI model has a context window — a hard upper limit on how much text it can process in one request.
- Browser extensions extract only the main article text, stripping navigation, ads, and boilerplate before sending anything to the model.
- When a page exceeds the context window, the extension must chunk it — splitting content and summarizing each piece, then combining the results.
- Chunking works well for most long-form content but can miss through-lines in documents where the argument builds across the whole text.
- Browsy sends text directly to your own API key — chunking and extraction happen inside the extension, never on an intermediary server.
On this page
Ask a browser AI to summarize a ten-paragraph article and you barely notice anything happening. Ask it to summarize a 15,000-word technical spec and you might wonder whether it actually read everything. Both requests look the same from your perspective — but under the hood they exercise different parts of the pipeline. Here’s what’s actually going on.
What a context window is
Every AI language model processes text in tokens — roughly pieces of words. A sentence like “the quick brown fox” becomes about four tokens. A context window is the maximum number of tokens the model can hold in one request: everything you’ve sent it, plus the response it’s generating, must fit within that limit.
For the models Browsy supports today, context windows range from around 32,000 to over 1,000,000 tokens — roughly 25,000 to 750,000 words. Most web articles fit comfortably. But technical documentation, research papers, and long-form journalism can exceed even large context windows when pulled in full.
How the extension extracts page text
Before any text reaches the model, the content script in Browsy extracts the article body and discards everything else:
- Navigation menus, headers, and footers
- Cookie consent dialogs and paywalls
- Sidebar widgets, comment sections, and related-article links
- Advertisements and tracking iframes
What remains is usually 5–25% of the raw HTML page size. A 200 KB news article page typically reduces to 3–10 KB of extractable article text — comfortably within any modern context window.
This extraction step is not AI. It’s a set of rules that look for article content signals in the DOM: <main> tags, <article> elements, role="main" attributes, and similar indicators. Extraction happens entirely inside the extension before any request is formed.
What happens when the page is too long
For content that genuinely exceeds the context window after extraction — long documentation pages, multi-chapter guides, full transcripts — the extension uses chunking:
- The extracted text is split into overlapping chunks, each sized to fit within the model’s limit minus the instructions and expected response space.
- Each chunk is summarized independently.
- The per-chunk summaries are combined into a final summary in a second pass.
The overlap between chunks ensures continuity. A sentence that spans a chunk boundary isn’t silently dropped: the summary of chunk N starts slightly before where chunk N−1 ended, so ideas that bridge the two chunks are captured in at least one summary.
The accuracy trade-off in chunked summaries
Chunking works well for most long-form content — particularly for structured writing where each section stands reasonably on its own. It works less well in three specific situations:
Arguments built across the whole document. If a paper spends 5,000 words building toward a conclusion that only makes sense in context, chunked summarization may paraphrase each part correctly but miss the through-line.
Cross-references. “As discussed in section 3…” summarized from section 7 doesn’t automatically have access to section 3’s summary unless the combiner pass is sophisticated.
Nuanced caveats. A heavily qualified claim that appears at the end of a long document, qualifying something stated confidently at the start, requires the full document context to represent accurately.
These are known limitations of chunked summarization, not bugs specific to Browsy or any other tool. For documents where end-to-end coherence matters, asking about a specific section usually gives better results than a single whole-document summary request.
How to get better results on long pages
Highlight a specific section before asking for a summary. Browsy reads selected text when something is highlighted, keeping the request within context without chunking.
Ask a specific question rather than “summarize this.” “What does this article say about the methodology?” focuses the model on the relevant section.
For very long documents, go section by section. “Summarize the introduction,” then “summarize the findings section” — each call is fast and accurate, and you control the structure of the result.
How Browsy specifically works
Browsy extracts article text using its content script, estimates the token count client-side, and decides whether to send the full text or chunk it. That decision logic runs inside the extension — no server is contacted to figure out how to handle your page. The resulting request goes directly to the AI provider (Gemini or Grok, depending on your configuration) using your own API key.
No intermediate server sees your text at any step in this process. The chunking and merging logic is part of the extension itself, not a cloud service Browsy operates on your behalf. That’s the BYOK architecture at work: the tool is a client, not a middleman.
If you’re curious about how context windows relate to the model’s intelligence — rather than just memory — see our explanation of how context windows power AI answers. For a deeper look at how the page text extraction works in practice, this post on how AI browser extensions read pages covers the content-script side of the pipeline.