XPath tester that can see into shadow roots

The tester runs entirely in your browser. The markup you paste is parsed into a document that is never attached to the page, and the expression is evaluated with the browser's own XPath engine, the same document.evaluate a Playwright or Selenium locator ends up calling. Nothing you paste leaves the tab; there is no server round trip, and the usage journal records only that the tool was opened.

What XPath 1.0 can and cannot express

Browsers implement XPath 1.0. That gives you axes, predicates, contains(), normalize-space(), starts-with(), text() and positional filters. It does not give you matches(), ends-with() or anything from XPath 2.0 and later, so an expression that works in an XML toolkit can fail in a browser without being wrong. The tester reports the engine's error message where that happens.

Why shadow roots need special handling

An XPath expression stops at a shadow boundary. A web component that renders its button inside a shadow root is invisible to //button evaluated from the document, which is why a locator that works on one site fails on a portal built from components. Declarative shadow DOM, the template element with shadowrootmode, makes this common on server-rendered pages too.

The tester handles it the way Browserberg's perception layer does: the expression is evaluated in the document and then again inside every shadow root, and a match inside a root is reported with a composed path, the path to the host element followed by the path inside its tree. That is the address an agent uses when it needs to click something a plain XPath cannot reach.

The ambiguity rule

In the product, an XPath is one rung on a five-rung ladder of element identity. When a cached plan is replayed, each rung is tried in turn, the rung that matched is recorded, and an expression that matches more than one element is refused as ambiguous rather than resolved to the first hit. The tester shows the match count for that reason. One is the number you want.

What the tester does not judge

It matches against the markup you pasted, not against a live page, so anything a script adds after load is absent unless you paste the rendered DOM. It says nothing about whether a matched element is visible, enabled or actually clickable; that is the agent view's job, where clickability is four signals with a recorded reason and reachability is a hit test rather than rectangle geometry. And it does not tell you whether the expression will survive the next deploy: a path built from generated class names matches today and nothing tomorrow. Prefer text, roles and stable attributes.