---
title: 'PageGuide: DOM-Grounded Web Assistance'
url: https://www.emergentmind.com/topics/pageguide
type: topic
---

# PageGuide: DOM-Grounded Web Assistance

Searching arXiv for PageGuide and closely related GUI/page-guidance work to ground the article in current papers.
PageGuide is a grounded web-assistance system introduced as a **Manifest v3 Chrome browser extension** that helps users directly on live webpages by grounding large-language-model outputs in the **HTML DOM** and rendering those outputs as **visual overlays** on the page itself. Its core claim is that many browsing tasks are better served by **inspectable assistance** than by opaque automation: rather than returning answers without page-level evidence or executing hidden action sequences, PageGuide highlights supporting evidence in situ, presents one procedural step at a time, and lets users review semantic hiding decisions before the page is modified [2604.23772].

## 1. System concept and design position

PageGuide is organized around three user-facing modes: **Find**, **Guide**, and **Hide**. These modes address three distinct browsing needs identified in the paper: locating and highlighting relevant evidence on the current page, showing step-by-step instructions one at a time so users can perform actions themselves, and hiding distracting content while preserving user control over what is removed [2604.23772].

The system is explicitly positioned against both general AI assistants and browser agents. The paper argues that systems such as ChatGPT, Gemini, Claude, Operator, and Browser Use can answer questions or automate interactions, but they typically return answers without page-level evidence and automate actions without transparent step-level grounding. PageGuide’s response is to make the webpage itself the primary output surface. The page is not only input to a side panel; it is also the place where answers, action targets, and hide decisions are rendered and inspected [2604.23772].

A central distinction in the paper is that PageGuide is a **mixed-initiative copilot**, not a fully autonomous browser agent. In **Guide**, for example, it highlights the next target and presents the current instruction plus an outcome hint, while the user retains control through **Next** and **Stop**. This design aligns PageGuide with assistance paradigms that preserve user agency rather than replacing it [2604.23772].

## 2. DOM-grounded architecture and interaction pipeline

PageGuide reads the current webpage through a **Set-of-Marks (SoM)**-style indexing process. Every visible, text-bearing, or interactive node is assigned a unique integer index, yielding

\[
\mathcal{D} = \{(id_j,\, \text{text}_j,\, \text{tag}_j,\, \text{bbox}_j)\}_{j=1}^{m}
\]

where each indexed element stores a unique integer ID, textual content, HTML tag type, and on-screen bounding box. This indexed representation is what the language model receives instead of raw HTML [2604.23772].

Routing is handled by an LLM-backed classifier that maps the user query and compact page context to one of the three primary modes. In the paper’s notation,

\[
\text{mode} = f_{\text{router}(q, C), \text{where~~~mode} \in \{\text{Find, Guide, Hide}\}.
\]

The appendix prompt supports additional handlers such as `image_find` and `pdf_find`, but the core system is organized around `Find`, `Guide`, and `Hide` [2604.23772].

The resulting pipeline is structurally simple. PageGuide first reads and structures the page, then routes the query, then mutates the live page through mode-specific overlays or DOM edits. The important architectural property is unification: all three modes reuse the indexed DOM representation and differ mainly in prompt structure and in the way returned element indices are materialized on the page [2604.23772].

This DOM-grounded formulation distinguishes PageGuide from adjacent work that grounds answers or plans in latent reasoning without modifying the webpage itself. The benchmark **GuideWeb**, for example, formalizes page-level guidance as selecting **guide target elements** and generating **guide text** over raw HTML, DOM trees, and XPath-grounded elements, but it is a benchmark for automatic guide generation rather than a browser extension that renders grounded assistance on the live page [2602.01917].

## 3. Find, Guide, and Hide

PageGuide’s three modes share a single grounding substrate but differ in how they transform model output into user-visible intervention.

| Mode | Objective | Page-level manifestation |
|---|---|---|
| Find | Answer questions with evidence on the current page | Highlighted evidence spans and clickable citations |
| Guide | Assist with multi-step procedures one step at a time | Pulsing beacon, anchored tooltip, side-panel step and hint |
| Hide | Suppress distracting content based on semantic intent | Reviewable candidate list, then `display:none` on confirmation |

In **Find**, the model answers the query and inserts inline citations tied to indexed DOM elements. The system prompt requires factual claims to be supported with exact supporting snippets, using citation forms such as `[N:"exact phrase"]` in the appendix. PageGuide then resolves each citation by locating the element with index `N`, matching the cited phrase, wrapping the span in a color-coded animated overlay, and scrolling to the first cited element. The side panel displays the answer with clickable citations, and the page displays the evidence directly where it appears [2604.23772].

In **Guide**, the model produces an ordered plan

\[
P = (a_1, a_2, \ldots, a_k)
\]

where each action includes a natural-language instruction, the SoM index of the target DOM element, and an action type. The paper lists `click`, `type`, `scroll`, and `navigate` as action types, and the appendix’s step-by-step JSON prompt also includes a `waitFor` field with values such as `"click"`, `"input"`, `"scroll"`, or `null`. PageGuide surfaces one step at a time: the target element receives a pulsing beacon, the instruction is shown as a tooltip anchored to that element, and the side panel shows the current instruction, a one-sentence outcome hint, and **Next**/**Stop** controls. After each confirmed step, the DOM is re-read; if the resulting page diverges from expectation, the remaining plan is regenerated [2604.23772].

In **Hide**, the model returns a ranked set of candidate elements together with a one-sentence justification and a short snippet for each candidate. The condensed prompt instructs the model to return only elements that clearly match and not to include borderline cases; the appendix caps the output at 15 items. Before any DOM mutation occurs, PageGuide presents a floating summary popup with numbered badges, reasons, snippets, jump controls, and checkboxes. Only after user confirmation does the extension hide the selected elements by applying `display:none` [2604.23772].

The three modes correspond to different forms of grounding. **Find** grounds factual claims in evidence spans; **Guide** grounds procedural instructions in interactive targets; **Hide** grounds semantic filtering requests in specific page elements. A plausible implication is that PageGuide treats grounding not as a single retrieval problem but as a family of output-to-DOM alignment problems.

## 4. Empirical evaluation

PageGuide is evaluated in a **controlled within-subject experiment** with **\(N = 94\)** participants. Each participant completed six tasks in total—two per mode—with one task under **unaided browsing** and one under the extension condition, with ordering counterbalanced and a **3 minute maximum per task** [2604.23772].

The user-study results reported in the abstract are strong across all modes. **Hide** accuracy improves by **26 percentage points** with an **86.7% relative gain**, and task completion time drops by **70%**. **Guide** completion rate increases by **30 percentage points**. **Find** reduces manual search effort, with `Ctrl+F` usage falling by **80%** and task time decreasing by **19%** [2604.23772].

The main text gives the per-mode breakdown. In **Find**, control accuracy is **81%** and extension accuracy is **86%**, with a paired Student’s t-test of \(t = -1, p = 0.32\); completion time for correctly completed tasks drops from a control median of **65.2 s** to **52.8 s**, with \(t = 2.31, p = 0.024\). Interaction traces show `Ctrl+F` usage falling from **0.26** to **0.05** per task, text selection from **0.18** to **0.08**, scroll count from about **13** to **5**, mouse clicks from **8.22** to **4.78**, and mouse movement distance from **6968 px** to **5490 px** [2604.23772].

In **Guide**, correct terminal-state completion rises from **23%** in control to **53%** with PageGuide, with \(t = -5.1, p < 10^{-8}\). For correctly completed trials, completion time falls from **95.8 s** to **66.7 s**, with \(t = 4.88, p < 10^{-4}\). The paper notes that page visits and mouse movement distance can increase in this mode because guidance deliberately directs users across pages rather than merely reducing exploratory within-page search [2604.23772].

In **Hide**, accuracy rises from **30%** to **56%**, with \(t = -4.4, p < 10^{-5}\). Median completion time drops from **104 s** to **31.7 s**, with \(t = 9.99, p < 10^{-13}\). The paper also reports a qualitative shift in self-reported full completion from **28%** to **83%** [2604.23772].

Component-level evaluation supports the interaction design. The router achieves **97.68%** overall classification accuracy, including **97.4%** on Find, **100.0%** on Guide, and **97.2%** on Hide. Additional evaluations include Find on Natural Questions and QASPER, Guide on Online-Mind2Web, and Hide on a self-collected dataset; for Guide on Online-Mind2Web, **PageGuide + Gemini 3 Flash** reaches **35.17** average task success versus **30.00** for the SeeAct baseline [2604.23772].

## 5. Relation to adjacent research on page-level guidance and GUI assistance

PageGuide sits within a broader research shift from opaque automation toward grounded, assistive, and page-aware systems, but it is not identical to several similarly named or conceptually adjacent works.

**GuideWeb** defines a benchmark for automatic in-app guide generation on real-world web UIs. It formalizes page-level guidance as selecting **guide target elements** grounded in the webpage and generating intent-aligned guide text. Its structured output is \(y = (g, \mathcal{A})\), where \(g \in \{0,1\}\) indicates whether the page needs guidance and \(\mathcal{A}\) is the set of element-grounded guide annotations. GuideWeb reports **30.79%** guide target element prediction performance for its task-specific **GuideWeb Agent**, together with **44.94** BLEU for intent generation and **21.34** BLEU for guide-text generation, showing that automatic page-level guide authoring remains difficult [2602.01917].

The benchmark **GUIDE (GUI User Intent Detection Evaluation)** addresses a different aspect of assistance: understanding the user rather than grounding answers in the page. It contains **67.5 hours** of screen recordings, **120** videos from **54 novice users**, across **10 applications**, and defines three tasks—**Behavior State Detection**, **Intent Prediction**, and **Help Prediction**. Across eight multimodal models, the best baseline reaches only **44.61%** on behavior-state detection and **55.00%** on help-content prediction, while adding structured user context can raise help prediction substantially. This suggests that effective guidance is not only a grounding problem but also a user-state and intent-inference problem [2603.25864].

In GUI-agent research, **PG-Agent** reorganizes prior interaction episodes into **page graphs** whose nodes represent recurring pages and whose edges represent action-induced transitions. It then retrieves page-level guidance from those graphs for planning and decision-making. On **AITW**, PG-Agent reports an overall score of **59.5**, beating **Qwen2.5-VL-72B** at **48.1** and **OmniParser** at **57.5**; on **Mind2Web**, it achieves **52.9**, **48.7**, and **53.3** Step SR across Cross-Task, Cross-Website, and Cross-Domain splits. This is a page-graph retrieval architecture rather than a browser extension, but it shows a complementary form of page-aware guidance: structural priors over page transitions rather than DOM-grounded overlays [2509.03536].

The framework **GUIDE: Resolving Domain Bias in GUI Agents through Real-Time Web Video Retrieval and Plug-and-Play Annotation** is conceptually related but not nominally the same system. That paper explicitly states that the term **“PageGuide” does not appear in the paper** and presents a different mechanism: real-time retrieval of web tutorial videos, automated annotation through an inverse-dynamics pipeline, and injection of planning and grounding knowledge into existing GUI agents. On **OSWorld**, it reports **4.5–7.5 percentage point** improvements across architectures without modifying model parameters [2603.26266].

Taken together, these works indicate several distinct notions of “guidance”: DOM-grounded user-facing assistance on live webpages, automatic guide authoring over DOM snapshots, user-state-aware help prediction in open-ended GUI tasks, page-graph retrieval for agent planning, and video-derived domain expertise for GUI agents. PageGuide occupies the most explicitly user-facing point in this design space.

## 6. Limitations, trade-offs, and significance

The paper identifies several limitations. In **Find**, dense pages can produce too many highlights, and highlights do not persist across page transitions. In **Guide**, per-step confirmation can introduce overhead for experienced users who already know the workflow. In **Hide**, confirmation dialogs can become cumbersome when many candidate elements are returned, and the system has **no cross-session memory**, so preferences must be restated each time [2604.23772].

A broader limitation is routing granularity. Current routing chooses exactly one mode per query, so composite requests such as finding a settings page and then guiding the user through a task are not automatically decomposed into chained operations. The paper proposes a future multi-step planner that could invoke modes sequentially, such as `Find → Guide` [2604.23772].

A common misconception would be to interpret PageGuide as primarily a browser automation system. The paper argues the opposite: fully autonomous browser agents are often the wrong abstraction for factual verification, unfamiliar procedures, and personalized content suppression. PageGuide’s contribution is to preserve user oversight while making model outputs inspectable on the live page. This suggests a broader significance beyond the extension itself: DOM grounding can function as a transparency mechanism, not merely as a control interface [2604.23772].

Another misconception would be to treat page guidance as equivalent to page understanding. The broader literature indicates that page-level assistance decomposes into multiple technical problems: target-element selection and microcopy generation in GuideWeb, user-state and help-timing inference in GUIDE, page-transition retrieval in PG-Agent, and domain-specific planning and grounding knowledge in GUIDE’s video-retrieval framework [2602.01917] [2603.25864] [2509.03536] [2603.26266]. PageGuide addresses one particularly concrete and deployment-oriented subset of this agenda: grounded assistance directly rendered on the webpage.

In that sense, PageGuide can be understood as an operational synthesis of several research threads. It uses DOM-grounded indexing to make model references executable on the page, uses mixed-initiative interaction to preserve agency, and demonstrates through user study that page-grounded assistance can improve verification, procedural success, and semantic content filtering on live webpages [2604.23772].

Source: https://www.emergentmind.com/topics/pageguide