Skip to content
Browserberg Browserberg
Free tool

What does an AI agent see on your page?

Not the pixels. A browser agent reads a tree of roles, names and controls, and pays for it in tokens. This tool loads your URL in an EU-hosted Chromium and shows that tree at three fidelities next to the screenshot a person would see.

Start free Book a call

Enter a public URL. The scan opens it in a fresh browser, waits for the page to settle and returns the tree, the controls and a screenshot.

This check opens a real browser on our servers and needs JavaScript in yours.

Observations, not verdicts. What you enter is processed for this result and written to a usage journal described in the privacy policy; nothing else is stored.

Reading the result

  1. Compare the three fidelities

    Full keeps every node with text. Economy collapses decoration and repeats. Lean keeps controls and headings. Each tab shows characters, lines and an estimated token count.

  2. Scan the controls table

    One row per interactive element: its encoded id, role, accessible name, whether it has a name at all, and whether it is clickable only through script.

  3. Read the clickability reasons

    An element is listed as clickable for a stated reason, or not clickable for one: covered by another element, zero size, disabled, off screen. The reason is what you fix.

  4. Hold the tree against the screenshot

    Anything you can see in the image and cannot find in the tree is invisible to an agent. Usually an icon-only button, a div with an onclick, or text drawn on canvas.

How the view is produced

The scan runs the agent-view report in an ordinary Browserberg session, with no model involved. A container starts, Chromium navigates to the URL, and the perception layer, the same browser-side code that feeds every agent run, walks the live DOM and builds the tree. It is the same code, not a lookalike, which is the point: what you read here is what an agent would be handed.

Roles and names, not tags

The tree is built from the accessibility semantics of the page rather than from tag names. A div with role=button and an aria-label is a button with a name; a button containing only an SVG is a button without one. hasAccessibleName in the controls table is the single most useful column for a developer, because an agent addressing a control by name cannot address one that has none, and the fallback is a positional guess.

Clickability is four signals with a reason

Whether an element can be clicked is decided from four signals, and the reason is recorded rather than folded into a boolean. Reachability is tested with a hit test at the element's point, document.elementFromPoint, not by comparing rectangles: a button under a transparent overlay has a perfectly good bounding box and cannot be clicked. jsClickable marks elements that react only through a script handler, which an agent can still use but which a screen reader cannot name and a keyboard cannot reach.

The token estimate is an estimate

The number beside each fidelity is characters divided by four, labelled as such. Real tokenisers differ by model and by language, and German compound nouns tokenise worse than English. The estimate is good enough to compare pages and fidelities against each other, which is what it is for. A page whose lean view still costs eight thousand tokens is telling you something about its structure.

Three fidelities

An agent does not always need the whole page. Full is what the verifier reads when it judges whether a task is done, economy is what a step usually plans against, and lean is what a long run keeps in context between steps. Seeing all three side by side shows what gets lost at each level, and whether the control you care about survives to lean.

What the tool does not judge

It reports structure, not quality. A page with a small, well-named tree is easier for an agent, but the tool does not score it, rank it or compare it with anyone else's. It sees the page as it settled after load, in a fresh profile with an EU address, so anything behind a login, a geo-redirect or a later interaction is absent. The consent banner, if there is one, is part of the page and appears in the tree as the agent would meet it. And the screenshot is there for comparison, not evidence: an agent does not read it.

Who uses this

Front-end developers

Before shipping a component, check that its controls have names and are reachable. The controls table is a faster loop than an accessibility audit for the two things agents trip over.

People building agents

Estimate what a page costs per step at each fidelity, and see whether the element your instruction names exists in the tree under that name.

Anyone debugging a failed run

The run said it could not find the button. Load the page here and look at the reason column: covered, zero size, no name, or genuinely absent.

Questions about the agent view

Does an AI agent see the page like a person does?

Usually not. Most browser agents read a text tree of roles, names and controls derived from the DOM and accessibility semantics; screenshots are a supplement in some systems. This tool shows the tree Browserberg agents read.

How many tokens does a web page use?

It varies by orders of magnitude. A clean product page may be two thousand tokens at lean fidelity; a portal home page with mega menus can pass thirty thousand at full. The tool shows an estimate per fidelity so you can compare.

Why is my button listed as not clickable?

The reason column says which of the four signals failed. The common ones are an overlay covering the element at its centre point, a zero-size box, a disabled attribute, and a position outside the viewport.

Can I run this on a page behind a login?

Not with the public tool. The same report is available in your own session after a vault login, and in the SDK as agentView.

Is the screenshot what the agent uses?

No. It is included so you can hold the tree against what a person sees. The agent works from the tree.

The same report from your own session

import { Browserberg } from '@browserberg/sdk';

const bb = new Browserberg({ apiKey: process.env.BROWSERBERG_API_KEY });

await using session = await bb.sessions.create();
const view = await session.agentView({
  url: 'https://www.example.de/',
  fidelities: ['full', 'economy', 'lean'],
  screenshot: true,
});

for (const v of view.views) console.log(v.fidelity, v.chars, v.lines);
console.log(view.controls.filter((c) => !c.hasAccessibleName).length, 'controls without a name');

Read next

Read the tree of any page you automate

Five browser hours, no card. Call agentView from your own session, behind logins included.

Start free Book a call