PageGuide: DOM-Grounded Web Assistance

• PageGuide is a DOM-grounded web-assistance system that integrates large-language-model outputs with HTML evidence rendered directly on live webpages.
• It offers three interactive modes—Find, Guide, and Hide—that highlight evidence, provide step-by-step instructions, and suppress distractions using an indexed DOM representation.
• Empirical evaluations show that PageGuide significantly improves task accuracy, reduces manual search efforts, and lowers completion times by enabling actionable, inspectable guidance.

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 (Nguyen et al., 26 Apr 2026).

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 (Nguyen et al., 26 Apr 2026).

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 (Nguyen et al., 26 Apr 2026).

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 (Nguyen et al., 26 Apr 2026).

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 LLM receives instead of raw HTML (Nguyen et al., 26 Apr 2026).

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 (Nguyen et al., 26 Apr 2026).

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 (Nguyen et al., 26 Apr 2026).

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 (Gan et al., 2 Feb 2026).

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 (Nguyen et al., 26 Apr 2026).

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 (Nguyen et al., 26 Apr 2026).

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 (Nguyen et al., 26 Apr 2026).

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 (Nguyen et al., 26 Apr 2026).

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% (Nguyen et al., 26 Apr 2026).

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 (Nguyen et al., 26 Apr 2026).

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 (Nguyen et al., 26 Apr 2026).

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% (Nguyen et al., 26 Apr 2026).

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 (Nguyen et al., 26 Apr 2026).

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 $\text{mode} = f_{\text{router}(q, C), \text{where~~~mode} \in \{\text{Find, Guide, Hide}\}.$0, where $\text{mode} = f_{\text{router}(q, C), \text{where~~~mode} \in \{\text{Find, Guide, Hide}\}.$1 indicates whether the page needs guidance and $\text{mode} = f_{\text{router}(q, C), \text{where~~~mode} \in \{\text{Find, Guide, Hide}\}.$2 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 (Gan et al., 2 Feb 2026).

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 (Yang et al., 26 Mar 2026).

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 (Chen et al., 27 Aug 2025).

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 (Xie et al., 27 Mar 2026).

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 (Nguyen et al., 26 Apr 2026).

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 (Nguyen et al., 26 Apr 2026).

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 (Nguyen et al., 26 Apr 2026).

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 (Gan et al., 2 Feb 2026, Yang et al., 26 Mar 2026, Chen et al., 27 Aug 2025, Xie et al., 27 Mar 2026). 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 (Nguyen et al., 26 Apr 2026).