Google Uses Chrome to Supply Context to Gemini Chat

When you share a Chrome tab with Gemini, Chrome doesn't just send the page's HTML. It runs a system called the Page Content Agent — part of its rendering engine — that walks the browser's internal representation of the page and builds a structured tree of everything on screen: every heading, link, button, image, form field, and table cell, each tagged with a unique node ID, bounding box coordinates, text styling, and interaction data.

That tree is then converted into structured Markdown with node references and passed to Gemini as grounded context. The AI can read the page, reference specific elements by ID, and interact with them — clicking buttons, filling forms, following links — all through this structured representation.

This article breaks down exactly how that system works, based on Chromium's open-source code and direct testing with Gemini to reveal what it actually receives.

Page Content Agent

Walks the browser's internal rendering tree and produces a tree of content nodes. Each node gets a type, geometry, text styling, interaction info, and accessibility data.

A Complete List of Node Types:

1. Root — The top-level container for the entire page
2. Container — A grouping element (e.g. div) that holds other nodes
3. Text — A piece of visible text content
4. Paragraph — A block of text (maps to <p> tags)
5. Heading — A title or subtitle (h1 through h6)
6. Anchor — A clickable link
7. Image — An image element
8. SvgRoot — The root of an inline SVG graphic
9. Canvas — A drawable canvas area
10. Video — A video player element
11. Form — A form container (groups inputs together)
12. FormControl — An interactive input (text field, dropdown, button, etc.)
13. Table — A data table
14. TableRow — A single row within a table
15. TableCell — A single cell within a table row
16. OrderedList — A numbered list
17. UnorderedList — A bulleted list
18. ListItem — A single item within a list
19. Iframe — An embedded page within the page
20. DialogModal — A popup dialog that blocks page interaction
21. DialogModeless — A popup dialog that allows page interaction

Geometry

There are three types of bounding box per node:

1. Outer bounding box - The full rectangle the element occupies on screen, including parts that might be hidden behind other elements or clipped by a scrollable container
2. Visible bounding box - The portion of the outer box that's actually visible to the user (clipped by scroll containers, parent boundaries, and the viewport edges)
3. Fragment bounding boxes - When an element wraps across multiple lines (like a long link that breaks mid-sentence), each line segment gets its own separate rectangle. Only present when there are 2+ fragments

Each box is defined by x, y, width, height in viewport pixel coordinates. There's also a CSS position value per node (static, relative, absolute, fixed, sticky) since that affects how the element is positioned on the page.

Text Styling

1. Text size — Ratio of the element's font size to the page's base font size, bucketed into XL, L, M, S, XS (so a heading that's 2x the base size = XL, normal body text = M, fine print = XS)
2. Has emphasis — Whether the text is visually stressed: bold, italic, underlined, or superscript/subscript
3. Color — The RGBA color value of the text

Accessibility

Two levels — per-node interaction info and page-level landmark roles.

Per-node interaction info:

1. Is focusable — Can the element receive keyboard focus
2. Is tabbable — Can the user Tab to it (focusable + has a non-negative tab index)
3. Is disabled — Element is grayed out / non-interactive
4. Clickability reasons — Why the element is considered clickable (16 possible reasons): clickable control, has click events, has mouse hover events, has mouse click events, has key events, is editable, has cursor:pointer style, has :hover CSS pseudo-class, has an ARIA role implying clickability, has aria-haspopup, is an ARIA toggle, is ARIA selectable, has aria-expanded=true, has aria-expanded=false, has autocomplete, has a tabindex
5. Disabled reasons — Why interaction is blocked: aria-disabled, HTML disabled attribute, cursor:not-allowed style
6. Z-order — The element's stacking position in the document (which elements sit on top of which)
7. Scroller info — If the element is a scroll container: its total scrollable area, visible area, and whether it scrolls horizontally, vertically, or both

Landmark roles (annotated on container nodes):

1. Header — Page or section header
2. Nav — Navigation block
3. Search — Search functionality area
4. Main — Primary content area
5. Article — Self-contained content piece
6. Section — Thematic grouping
7. Aside — Sidebar / tangential content
8. Footer — Page or section footer
9. ContentHidden — Content hidden via CSS content-visibility
10. PaidContent — Content behind a paywall

Labels:

1. aria-label — Explicit text label set on the element
2. aria-labelledby — Label composed by referencing the text content of other elements by ID

Output Formatters

Once the Page Content Agent builds the node tree, three formatters can convert it into different output formats:

1. Inner Text Builder — Takes the node tree and flattens it into plain text. Like copying a page and pasting into Notepad. All structure is lost, just the readable words remain.
2. Inner HTML Builder — Takes the node tree and produces cleaned-up HTML. Structured markup but stripped of scripts, styles, and noise.
3. Document Chunker — Splits the extracted text into passage-sized chunks suitable for feeding into an LLM context window. Handles splitting at sentence and paragraph boundaries so chunks don't break mid-thought.

Privacy

APC applies several privacy protections during the tree walk, controlling what content reaches the AI:

1. Password redaction — Password field values are never included in the output. This covers native password inputs, fields using CSS -webkit-text-security to mask characters, and fields that were ever set to type "password" even if later changed to plain text.
2. Cross-origin iframe redaction — If an embedded page (iframe) comes from a different domain, its content is replaced with redacted metadata (just the origin). Only same-origin iframes have their content included.

Node IDs

Every node in the tree gets two possible identifiers:

1. content_node_id — A sequential number assigned to every node via depth-first traversal (1, 2, 3, ...). Every node gets one. This is what the AI uses to reference specific parts of the page.
2. dom_node_id — A selective ID assigned only to nodes whose types appear on an internal allowlist. Not every node gets one. This is kept selective to avoid growing Chrome's internal hash maps unnecessarily.

Supporting Modules

1. Paid content detection — Checks for schema.org markup (JSON-LD and microdata) indicating content is behind a paywall (isAccessibleForFree: false). Paywalled nodes are flagged so the AI doesn't leak content the user hasn't paid for.
2. Ad-related element detection — Heuristically identifies ad containers by matching common class names, IDs, and data attributes associated with ad networks.
3. Debug Utilities — Converts internal enum values to human-readable strings for logging and debugging. For example, turning node type number 5 into the string "Heading".
4. Frame Metadata Observer — Lets other parts of Chrome subscribe to notifications when page metadata changes (title, meta tags, etc.). Keeps APC's view of the page current as the page updates dynamically.

Enabling Page Interactions

This system isn't just for reading pages — it's designed to let the AI interact with them. Gemini can click buttons, fill forms, and navigate links by referencing specific nodes in the tree.

The challenge is that pages change dynamically. A button might shift position, a list might reorder, or new content might load. This is handled with a matching algorithm that identifies target elements by combining multiple properties — node type, interactivity, and location on the page. If there's ambiguity, it further verifies by comparing text content to make sure the right element is acted on.

Structured Markdown with Node References

One of the output formats is structured Markdown where each element is tagged with a unique ID that links back to the original node in the tree. For example:

# Welcome to Example {#2}

This is a paragraph of text. {#4}

[Click here](https://example.com) {#5}

These IDs are what make interaction possible. The AI can say "click element {#5}" and Chrome knows exactly which DOM node that refers to — no fragile CSS selectors or XPath queries needed.

Selective Node ID Allowlist

Not every node needs a DOM node ID. Assigning IDs broadly grows Chrome's internal hash maps, which hurts renderer performance even after extraction is finished.

An allowlist mechanism controls which node types receive a dom_node_id:

1. If no allowlist is set, IDs are emitted broadly (legacy behaviour).
2. If an allowlist is set (even empty), IDs are always emitted for required cases — actionable targets like buttons and links, and metadata-linked nodes such as focused elements, selections, and label references.
3. If the allowlist names specific node types, those types also get IDs.

The sequential content_node_id is unaffected — every node always gets one. The allowlist only controls the more expensive dom_node_id.

How It All Fits Together

A request comes in from one of Chrome's AI features. The Page Content Agent walks the rendering tree and produces a structured node tree. Privacy protections — password redaction, iframe redaction, paid content flagging — are applied during the tree walk itself, before any output is generated. Nothing sensitive reaches the formatters in the first place.

That tree can then be:

1. Serialized as JSON for direct consumption
2. Converted to structured Markdown with node ID references, enabling the AI to target specific elements on the page
3. Passed to the inner text builder for plain text output
4. Passed to the inner HTML builder for cleaned-up HTML
5. Run through the document chunker to split into LLM-sized passages

When the AI needs to interact with the page — clicking a button, filling a form, following a link — it references a node ID from the Markdown output. Chrome matches that ID back to the actual element on the page, verifying by type, position, and content to handle cases where the page has changed since extraction.

In Action

Here's how a broken down page looks like, this is https://dejan.ai/ home page:

# Header & Introduction

1. #467: Book a call
2. #465: Admin
3. #463: Sign out
4. #460: Edit page ↗
5. #458: DEJAN is an AI SEO agency...
6. #456: Our team uses use machine learning...
7. #454: We cover the main AI ecosystems...
8. #451: Book a conference call with our senior...
9. #449: Schedule a Call
10. #446: ENGAGED BY GLOBAL BRANDS.

Process & Capabilities

1. #437: HOW WE WORK
2. #435: The ARC Framework
3. #433: 01
4. #431: Association
5. #429: Map Connections
6. #427: We nurture a strong culture of testing...
7. #425: 02
8. #423: Relevance
9. #421: Find Connection Strength
10. #419: We innovate all the time. It’s in our DNA...
11. #417: 03
12. #415: Citations
13. #413: Selection Rate Optimization
14. #411: We see ourselves as an extension...

Bayesian Content Optimizer Features

1. #409: Bayesian Content Optimizer
2. #407: Become the source AI chooses.
3. #405: Content Optimizer is a content optimization...
4. #402: AI search has changed how content wins
5. #400: Your page can rank #1 and still never...
6. #398: When someone asks a question in ChatGPT...
7. #396: Content Optimizer is built for it.
8. #393: From one page to your whole site
9. #391: Optimize a single page against a single...
10. #388: What you get
11. #386: Every run turns analysis into changes...
12. #384: Competitive source analysis
13. #382: See your page measured against...
14. #380: Rank factor insights
15. #378: See which content attributes helped...
16. #376: Content briefs
17. #374: Optimization results turned into a clear...
18. #372: Citation-focused content improvements
19. #370: Sharpen the specific passages AI systems...
20. #368: An optimization narrative
21. #366: A plain-English summary of what worked...
22. #364: Optimizes for the decision, not the ranking
23. #362: Traditional SEO optimizes for where you sit...
24. #360: The mechanism is direct...
25. #359: ranker
26. #358: — then iteratively rewrites your page...
27. #356: It isn’t a checklist or a static score...
28. #354: This is not traditional SEO
29. #352: It works alongside your SEO...

Traditional SEO vs Content Optimizer Lists

1. #350: Traditional SEO
2. #348: 1. Optimizes for position on a search results page
3. #346: 2. Targets crawlers and ranking algorithms
4. #344: 3. Measured by keyword rankings and clicks
5. #342: 4. Guided by general best-practice checklists
6. #338: Content Optimizer
7. #336: 1. Optimizes for selection inside an AI answer
8. #334: 2. Targets the model’s source-evaluation step
9. #332: 3. Measured by whether the AI ranker prefers...
10. #330: 4. Guided by a measured, round-by-round contest

Optimization Steps & Case Study

1. #325: From baseline to the top of the set
2. #323: A single, transparent loop you can watch...
3. #321: Choose a query or topic
4. #319: Start with the question, entity, or search...
5. #317: Assemble the competitive set
6. #315: Content Optimizer pulls the live results...
7. #313: Establish a baseline
8. #311: An AI ranker scores your page against...
9. #309: Optimize round by round
10. #307: Each round, the engine forms a hypothesis...
11. #305: Converge on the winning version
12. #303: The loop repeats until your content is...
13. #301: Receive the brief
14. #299: When the run finishes, you get a plain-English...
15. #297: Client Success: OWAYO

Metric Table Data Rows

1. #294: Metric
2. #292: Apr 15, 2026
3. #290: May 31, 2026
4. #288: Percentage Points Up
5. #286: % Increase
6. #283: Share of Voice
7. #281: 2.18%
8. #279: 3.87%
9. #277: +1.69
10. #275: +77.52%
11. #272: Mention Share
12. #270: 2.06%
13. #268: 4.37%
14. #266: +2.31
15. #264: +112.14%
16. #261: Citation Share
17. #259: 2.30%
18. #257: 3.38%
19. #255: +1.08
20. #253: +46.96%

Campaign Narrative & FAQs

1. #249: BACKGROUND
2. #247: At the start of the AI Visibility...
3. #246: OWAYO
4. #244: wasn’t being recommended in AI assistant...
5. #242: AUDIT
6. #240: Using our bayesian content optimizer we found...
7. #238: CAMPAIGN
8. #236: An on-site optimisation followed by...
9. #234: FAQs
10. #232: Does this replace my SEO?
11. #230: No — it complements it. Traditional SEO gets...
12. #228: Which AI models does it optimize for?
13. #226: It models the source-selection behavior...
14. #224: Do I have to rewrite my whole page?
15. #222: No. Snippet mode tunes a single...
16. #220: Will optimized content be penalized by Google?
17. #218: No. The changes improve clarity, structure...
18. #216: How long does a run take?
19. #214: A single snippet run completes quickly...
20. #212: Can my editorial team keep control?
21. #210: Yes. Human-in-the-loop mode lets your team...
22. #208: What do I need to get started?
23. #206: A page — or a set of pages — and the queries...

Philosophy & Values

1. #204: AI Visibility Philosophy & Approach
2. #200: DEJAN’s methodology transcends traditional...
3. #199: We understand that AI models...
4. #197: Deep Understanding
5. #195: We move beyond surface-level metrics...
6. #193: Actionable
7. #191: Our insights translate directly into actionable...
8. #189: Testing.
9. #187: We nurture a strong culture of testing...
10. #185: Innovation.
11. #183: We innovate all the time. It’s in our DNA...
12. #181: Collaboration.
13. #179: We see ourselves as an extension...

Core Team Profiles

1. #177: Meet our core team
2. #175: We’re an all-senior team with experience...
3. #171: MIKE JOLLY
4. #169: DIRECTOR OF STRATEGY
5. #165: BLAKE WALSH
6. #163: SEO
7. #159: GIORDANO CHNG
8. #157: SEO
9. #153: LIAM BUTTERY
10. #151: SEO
11. #146: DAN PETROVIC
12. #143: AI SEO
13. #139: MARTIN REED
14. #137: TECHNICAL SEO
15. #133: BIANCA HALL
16. #131: PUBLIC RELATIONS
17. #127: ALEX PETROVIC
18. #125: SEO
19. #121: DANIELLE WHITE
20. #119: OPERATIONS
21. #115: MILOS DOSEN
22. #113: CFO
23. #109: JOSIP IVANOVIC
24. #107: DEVELOPER
25. #103: NEMEK NOWACZYK
26. #101: PPC
27. #97: DRAGAN GRUBACKI
28. #95: TECHNICAL SEO
29. #91: FINN ARROWSMITH
30. #89: OUTREACH

Testimonials, Media Mentions, & Footer

1. #87: We were given our very own bespoke internal...
2. #83: Scott Schulfer
3. #81: Senior SEO Manager
4. #79: Zendesk
5. #71: Featured In
6. #69: Dan Petrovic, an academic and consultant on...
7. #68: SEO and generative AI
8. #66: , said Google’s size, expertise and massive...
9. #64: Tim Biggs, The Sydney Morning Herald
10. #58: Dan Petrovic made a super write up...
11. #56: JASON MAYES
12. #54: WEB AI LEAD
13. #52: GOOGLE
14. #50: GOOGLE WEB AI
15. #42: Featured in “
16. #41: Moz Top 10
17. #39: “,
18. #38: twice
19. #36: .
20. #28: Moz Recommended Agency
21. #26: Book a conference call with our senior...
22. #24: Schedule a Call
23. #21: DEJAN
24. #19: AI SEO
25. #17: SRO
26. #15: Blog
27. #13: Models
28. #11: Book a call
29. #9: Concepts
30. #7: ·
31. #6: OKF bundle
32. #3: DEJAN SEO PTY LTD, trading as DEJAN AI.

What Gemini Actually Receives

The source code shows how Chrome extracts page content. But what does Gemini actually see on the other end? By asking Gemini directly, we can reveal the complete pipeline.

When you share a tab with Gemini, Chrome packages the extracted content into a structured schema. The data arrives wrapped in a type called LongFormContextResult — a backend label that tells Gemini the incoming data is external source material, not conversation. This separation ensures Gemini grounds its answers in the page content rather than its training data.

The Schema for a Webpage

When a webpage tab is shared, Gemini receives a structure like this:

{ "Webpage": { "SearchResults": [ { "query": "", "results": [ { "data_type": "LongFormContextResult", "extracted_text": "[full extracted page content]", "index": "0.1.84" } ] } ] }}

The Schema for a YouTube Video

Videos get a richer structure. Title, description, and transcript are delivered as separate blocks, with each transcript segment carrying timestamps:

{ "Webpage": { "SearchResults": [ { "query": "", "results": [ { "data_type": "LongFormContextResult", "extracted_text": "- YouTube\n\n© 2026 Google LLC", "index": "0.1.89" } ] } ] }, "Video": [ { "query": "Video Title", "results": [ { "data_type": "LongFormContextResult", "extracted_text": "Search Query Quality Classifier", "index": "0.1.90" } ] }, { "query": "Video Description", "results": [ { "data_type": "LongFormContextResult", "extracted_text": "[full video description]", "index": "0.1.91" } ] }, { "query": "Video Speech Transcript", "results": [ { "data_type": "LongFormContextResult", "extracted_text": "building on research from Google AI...", "start_time": "00:00:00", "end_time": "00:00:08", "index": "0.1.92" }, { "data_type": "LongFormContextResult", "extracted_text": "this model is designed to identify...", "start_time": "00:00:08", "end_time": "00:00:16", "index": "0.1.93" } ] } ]}

The Index System

Every piece of content Gemini receives is stamped with an index like 0.1.84. This index is the citation backbone. When Gemini references a specific piece of content, it traces back to the exact source block through this numbering system.

The Raw Structured Markdown

The extracted page content arrives as structured Markdown with node ID references — exactly the format described in the source code. By asking Gemini to show what it received, the raw input becomes visible:

# {#458} DEJAN is an AI SEO agency that makes global brands visible in AI search, chat, assistants and agents.

{#456} Our team uses use machine learning and mechanistic interpretability to understand exactly why AI systems recommend a brand, then make yours the brand they recommend.

{#449} *Schedule a Call*

## {#435} The ARC Framework

| {#294} *Metric* | {#292} *Apr 15, 2026* | {#290} *May 31, 2026* || {#283} *Share of Voice* | {#281} 2.18% | {#279} 3.87% |

Every heading, paragraph, link, image, table cell, and interactive element is tagged with a {#ID} that maps back to a specific node in the page's rendering tree. These are the same content_node_ids assigned during extraction by the Page Content Agent.

For a typical homepage, Chrome extracted 471 nodes from the full rendering tree but only passed 198 tagged nodes to Gemini in the structured Markdown — the actionable ones. Links, buttons, headings, text blocks, and table cells made the cut. Structural containers and layout wrappers were filtered out. Gemini gets what it can read or interact with, not the scaffolding.

Chrome Sends What You See

Chrome extracts the page exactly as rendered in the current session. This means Gemini receives the authenticated view — whatever the user sees, the AI sees.

In testing, a WordPress admin button appeared in the extracted nodes as {#460}: Edit page ↗ — visible only because the user was logged in. Admin UI elements, internal dashboards, draft content, and user-specific pricing all become part of Gemini's context if they're on screen.

In a more striking test, navigating to an online banking portal and asking Gemini for an account balance produced a correct answer. The bank's authenticated page — account balances and all — was extracted and sent to Gemini as structured node data.

This is by design. The Page Content Agent extracts the rendering tree as-is. Password field inputs are redacted, but displayed content is not filtered by sensitivity. From the extraction system's perspective, a bank balance is just a Text node with some numbers — no different from a news headline.

The whole session is saved and remains in user's AI Mode interaction history.