A sequential identifier assigned to each content node during extraction via depth-first traversal. These IDs appear in the structured Markdown output as {#ID} references, enabling the AI to target specific elements on the page for reading, citing, or interaction.
A sequential identifier assigned to each content node during Chrome's page extraction. As the Page Content Agent walks the rendering tree depth-first, every node receives a content_node_id: 1, 2, 3, and so on.
These IDs appear in the structured Markdown output that Gemini receives, tagged inline as {#ID} references. A heading might appear as # Welcome to Example {#2}, a paragraph as {#4} This is some text, a link as [Click here](https://example.com) {#5}. Every actionable element on the page gets one.
This is what makes page interaction possible. When Gemini needs to click a button, fill a form field, or follow a link, it references the node ID. Chrome matches that ID back to the actual DOM element on the page. A matching algorithm verifies the element by type, interactivity, and position, handling cases where the page has changed dynamically since extraction.
There are actually two kinds of ID. The content_node_id is assigned to every node and is what Gemini works with. The dom_node_id is more selective — assigned only to node types on an internal allowlist — because broad assignment grows Chrome's internal hash maps and hurts renderer performance. The allowlist always includes actionable targets (buttons, links) and metadata-linked nodes (focused elements, label references), with optional additional types configurable per request.
