XPath and CSS Selector Tester

Runs a CSS selector or an XPath expression against HTML you paste in and lists every node it matched, with a path back to each one, its visible text, and optionally its markup. Both modes use the engines your browser already ships, querySelectorAll for CSS and document.evaluate for XPath, so a selector that works here works in your scraper, your test, or your console. It also breaks the selector down into plain English, one line per step, which is usually enough to spot the mistake without running anything.

Pick CSS or XPath, type the selector, and paste the HTML underneath. Matches are highlighted in the markup and listed below with their path, so you can tell the second list item from the fifth. Turn on the markup option to see the full outerHTML of each hit. The mode, the selector, and the HTML all live in the URL fragment, so one link shares the whole test case with a colleague.

Testing a selector usually means a browser console on a page you cannot easily reshape, or a scraping site that wants a signup before it will run a second query. This page takes any markup you paste, runs both selector languages side by side, and puts no counter on how many times you press it. Everything runs in this tab, so your files and inputs never leave your device.

Which XPath version does the browser support?

XPath 1.0, which is what document.evaluate implements. Axes, predicates, and the common functions are all there: text(), last(), position(), contains(), starts-with(), normalize-space(), count(), and the name and local-name pair. XPath 2.0 and later additions such as matches(), ends-with(), and sequence types are not available in any browser, so an expression written for lxml or Saxon may need trimming.

Should I use a CSS selector or XPath?

CSS is shorter and faster for the common cases: tag, class, id, attribute, and the child and sibling combinators. XPath earns its keep when you need to walk upward to a parent or ancestor, select an attribute or a text node directly rather than the element holding it, or filter on the text a node contains. If a CSS selector can express it, prefer CSS, because every scraping library speaks it.

Why does my selector match here but not on the live site?

Three usual causes. The live page builds that part of the DOM with JavaScript, so the markup you copied from view source never contained it. The page is inside an iframe or a shadow root, which neither querySelectorAll nor XPath crosses. Or the class you keyed on is generated per build, so it changed since you copied the HTML. Pasting the markup from the browser's Elements panel rather than view source rules out the first one.