Why it matters
End-to-end tests, scrapers and analytics tags all depend on selectors that pick exactly the right elements. A selector that matches one element today can match three after a redesign, and finding out in production is painful.
This tester runs your selector or XPath against pasted HTML in an inert document, so no scripts run and nothing loads, and lists every match. It also gives a unique path for each element and translates CSS into XPath for tools that only accept XPath.
How it works
- InputHTML and a CSS selector or XPath
- In your browserRun by the browser's own selector engine
- OutputMatches, specificity and the XPath version
Where it fits in a designer's workflow
- Plan
- Design
- Build
- Test
- Launch
By the numbers
Show the numbers as a table
| Selector | IDs | Classes | Elements |
|---|---|---|---|
| nav li.item:not(.active) > a | 0 | 2 | 3 |
| a[href^='https'] | 0 | 1 | 1 |
| article[data-sku$='220'] h2 | 0 | 1 | 2 |
| h2 + p | 0 | 0 | 2 |
How to use it
- Paste the HTML of the page or component.
- Type a CSS selector or XPath, or pick an example.
- Read the matches and their paths.
- Copy the XPath version if your tool needs it.
FAQ
Does it run page scripts?
No. HTML is parsed into an inert document, so scripts don't run and images, styles and frames don't load.
Why does the live page match differently?
Scripts often add or change elements after loading. Paste the HTML from your browser's Elements panel to test the final page.
Can every CSS selector become XPath?
Most can. Pseudo-classes that depend on state (:hover, :checked) have no XPath equivalent and are flagged.
Which selectors are best for tests?
Ones based on roles, labels or data-testid attributes, which survive redesigns better than classes.
