Test XPath expressions and CSS selectors online — against pasted HTML or a live URL rendered with headless Chrome. See every match, its source snippet, and its absolute XPath. No signup.
Live fetch renders the page with headless Chrome via the WebScraping.AI API, so selectors run against the same DOM your scraper would see.
The same request that powers the live fetch above — rotating proxies, headless Chrome rendering, and selector extraction in one API call. The snippet updates as you type:
The /selected endpoint takes CSS selectors. For XPath, fetch the rendered page via /html and evaluate the expression with your own parser (lxml, Nokogiri, libxml) — or describe the fields you want and let /ai/fields skip selectors entirely.
2,000 free API credits · No credit card required
The XPath syntax you'll actually use for web scraping. Paste any example into the tester above — the sample HTML is built to match. For the full reference with explanations, see the XPath cheat sheet guide.
| Expression | What it selects |
|---|---|
//h3 | Every <h3> anywhere in the document |
//li[@class="product"] | Elements with an exact attribute value |
//li[contains(@class, "product")] | XPath contains() — attribute includes a substring (the right form for multi-class elements) |
//a[starts-with(@href, "/products")] | Attribute begins with a string |
//h3[contains(text(), "Keyboard")] | Elements whose text includes a string |
//li[1] / //li[last()] | First / last matching sibling |
//span[@class="price"]/text() | The text node itself, not the element |
//li/@data-sku | An attribute value |
//h3/following-sibling::span | Siblings after the matched element |
//span[@class="price"]/ancestor::li | Walk up to a containing element |
//li[not(contains(@class, "out-of-stock"))] | Exclude matches with a predicate |
count(//li) | Scalar result — the tester shows numbers, strings, and booleans too |
CSS selector examples for extraction — shorter than XPath for most jobs, and the syntax the /selected API endpoint takes directly.
| Selector | What it selects |
|---|---|
.product / #main | By class / by id |
li.product .price | Descendants: .price anywhere inside li.product |
ul.products > li | Direct children only |
[data-sku] / [data-sku="KB-201"] | Attribute present / exact value |
a[href^="/products"] | Attribute starts with ($= ends with, *= contains) |
li:nth-child(2) | Positional matching |
li:not(.out-of-stock) | Exclusion |
h3 + span / h3 ~ span | Adjacent / any following sibling |
h3, .price | Union of several selectors |
CSS selectors are shorter, easier to read, and cover the large majority of extraction jobs — prefer them
by default. XPath is the tool for what CSS can't express: matching on text content
(contains(text(), …)), walking up the tree (ancestor::), extracting
attribute values or text nodes directly, and computing scalars like count().
Browsers and this tester support XPath 1.0 — the same version implemented by lxml, Nokogiri, and most scraping libraries, so an expression that works here works in your scraper. One practical difference to know: a selector that matches in your browser can still return nothing in your scraper if the content is rendered by JavaScript — the fetch button above returns the JS-rendered DOM for exactly that reason.
How do I test an XPath expression online?
Paste your HTML into the tester (or fetch a live URL), pick XPath mode, and type the expression. Matches update as you type, with each element's source snippet and absolute XPath. Scalar expressions like count(//li) or string results are shown too.
Why does my selector work in Chrome DevTools but not in my scraper?
Usually because DevTools runs against the JavaScript-rendered DOM while your scraper fetched the raw HTML — the element you selected may not exist in the initial response. Use the live-URL fetch here to test against the rendered DOM, and fetch pages with JS rendering enabled in your scraper. A second common cause: XPath 2.0+ functions that browsers and lxml (both XPath 1.0) don't support.
Can I test selectors against a JavaScript-heavy page?
Yes — enter the URL and hit Fetch. The page is rendered with headless Chrome through the WebScraping.AI API, so dynamic content is present in the HTML your selector runs against. Live fetching is rate-limited; for unlimited use, sign up for a free API key with 2,000 credits.
Should I use XPath or CSS selectors for web scraping?
CSS selectors by default — they're shorter and cover most jobs. Switch to XPath when you need to match on text content, walk up the tree with ancestor::, select attributes or text nodes directly, or compute values like count(). Both run at comparable speed in modern engines.
Does the WebScraping.AI API support XPath?
The /selected and /selected-multiple endpoints take CSS selectors. For XPath, fetch the rendered page via /html and evaluate the expression with your own parser (lxml, Nokogiri, libxml). If you'd rather skip selectors entirely, /ai/fields extracts named fields from a page with an LLM.
Is this selector tester free?
Yes — free, no signup, no usage cap on testing against pasted HTML. Only the live-URL fetch is rate-limited, because it performs real scraping requests with proxies and headless Chrome.
Run the same selector against any site — proxies, headless Chrome, and parsing in one API call.