# How is the page represented to the model? > Browser & computer control — a good answer covers: DOM serialization, accessibility tree, screenshots, set-of-marks/element indexes; size limits and pruning. Canonical page: https://llms-technical-reviews.com/browser-control/q/page-perception/ ## Verdict Both projects send the model a text rendering of the page built from CDP, not raw HTML. They differ in how much they add on top. [browser-use](/p/browser-use/) merges `DOMSnapshot.captureSnapshot`, the full DOM and the accessibility tree. Its `DOMTreeSerializer` drops elements hidden by paint order and redundant wrappers, then prints interactive nodes as `[index]`. The index is the CDP `backend_node_id` where possible, so it stays stable across steps. New elements are starred. A screenshot is taken every step and sent when `use_vision` is on. Serialized text is capped at 40,000 characters. [Stagehand](/p/stagehand/) builds a "hybrid snapshot": an accessibility outline merged with DOM data, with iframes stitched in and shadow DOM pierced. Each line carries a `frameOrdinal-backendNodeId` id that maps to an XPath. Callers can scope it to a locator or exclude parts. There are no screenshots in `act` or `observe`. `extract` can attach a plain viewport PNG on request, with no set-of-marks overlay. Pick browser-use when pages are visual or ambiguous and a vision model is worth the extra tokens on every step. Pick Stagehand for cheaper, text-only prompts scoped to part of a page, especially for extraction. More projects in this category are being researched. ## Per-project answers ### browser-use/browser-use (answered) **DOM Serialization.** The agent represents pages through `SerializedDOMState` (`browser_use/dom/views.py:935`), which wraps a tree of `SimplifiedNode` objects built from three CDP sources: `DOMSnapshot.captureSnapshot`, the full accessibility tree via `accessibility.GetFullAXTree`, and the DOM document structure (`browser_use/dom/service.py:6-25`). The `DomService` class orchestrates this, combining snapshot bounds, AX node properties, and DOM nodes into `EnhancedDOMTreeNode` objects with sibling/shadow-root/iframe support. Cross-origin iframes with dimensions ≥ 10px each side are included (`browser_use/dom/service.py:40-42`). **Serialization to text.** `DOMTreeSerializer.serialize_accessible_elements()` (`browser_use/dom/serializer/serializer.py:114-165`) runs a pipeline: (1) create a simplified tree by filtering non-content elements (style, script, SVG decorative children) and detecting interactive elements; (2) paint-order filtering to skip elements visually occluded; (3) tree optimization (remove unnecessary parents); (4) bounding-box filtering that excludes children contained within propagating parents (`a`, `button`, `div[role=button]`) at 99% containment threshold; (5) assign numeric interactive indices to clickable/scrollable elements. The final `serialize_tree()` (`browser_use/dom/serializer/serializer.py:989`) renders a compact text format: `[index]` for interactive elements, ordinary `` for containers, `|scroll element|` markers for scrollable containers, `|SHADOW(open/closed)|` for shadow-DOM hosts, text nodes inline, and iframes with hidden-element hints showing scroll distances. Compound controls (date pickers, range sliders, file inputs, select dropdowns) get synthetic `compound_components=...` attributes with sub-role information (`browser_use/dom/serializer/serializer.py:1059-1100`). **Element indices (set-of-marks).** Interactive elements get sequentially numbered indices stored in a `DOMSelectorMap` (dict of `int → EnhancedDOMTreeNode`). The LLM sees `[1]