XPath Cheat Sheet: The Dozen Expressions That Survive

Copy this line to your agent to get typed fields out of a page without writing selectors at all.

set up https://monid.ai/SKILL.md and use context.dev /web/extract with a JSON Schema to pull fields from a page

Most XPath references list what the specification allows, sorted by syntax category, which is useful when you are learning and useless when a selector broke overnight. The expressions that matter are the ones still matching after somebody redesigned the page, and they are a much shorter list than the specification. This is that list, organised by how long an expression survives rather than by what it is called, running through Monid, the OpenRouter for agent tools.

What is XPath and when do you still need it?

XPath is a query language for navigating an XML or HTML document tree. CSS selectors do most of what people use it for, more readably, so the honest question is what is left.

Four things CSS cannot do

Select by text content. CSS has no way to say "the element containing this word". XPath does, and this is the single most common reason to reach for it.

Walk upwards. CSS selects descendants. It cannot say "the row containing this cell" or "the parent of the element with this id". XPath's axes go in every direction.

Select by an arbitrary attribute predicate. CSS handles attribute matching well, but combining several conditions with boolean logic gets awkward fast, and XPath's predicates handle it plainly.

Position relative to a sibling. "The element after this heading" is natural in XPath and painful in CSS.

Everything else, class matching, descendant selection, nth-child, is better expressed as a CSS selector, and if that covers your case you should use it. This is not a loyalty question. There is a copy-paste version of the whole extraction path, selectors included, in Any URL to LLM-Ready Markdown.

Why it still matters when a tool writes selectors for you

Because a generated selector is a guess about what will stay stable, and knowing which guess is a good one is the whole skill. The next section is about the guess your browser makes, which is reliably the worst one available.

📖 See also A Free API to Extract Page Content for RAG: Read This First

Why does the XPath your browser gave you break?

Because "Copy XPath" in developer tools produces an absolute path, and an absolute path encodes every structural decision between the root and your element.

What it actually gives you

Something like this:

/html/body/div[3]/div/main/div[2]/section[4]/div[1]/ul/li[2]/span

Read what that promises. The third div in the body. The second div inside main. The fourth section. Every one of those indices is a fact about the current layout that nobody guaranteed.

Add a banner above the content and div[3] becomes div[4]. The expression now matches something else, or nothing, and it does so silently, because a selector that matches nothing returns an empty result rather than an error.

The rule that replaces it

Anchor on something semantic and search downwards from there. A data- attribute, an id, a role, an itemprop, an aria-label. Those exist because somebody put them there deliberately, which means changing them is a decision rather than a side effect of moving a div.

//*[@data-testid='price']
//*[@itemprop='price']
//section[@id='reviews']//li

None of those cares where the element sits in the tree.

The durability ranking

Work down that table and stop at the first row the page supports. That is the entire method.

Which expressions actually survive a redesign?

The working set, roughly a dozen, organised by what they anchor on.

Attribute anchors, the durable ones

//*[@data-testid='product-price']          any element with a test id
//*[@itemprop='name']                       schema.org microdata
//a[@rel='next']                            pagination, semantically marked
//*[@role='navigation']//a                  links inside a nav landmark
//*[contains(@class,'price')]               class fragment, when classes are semantic

That last one deserves a warning. contains(@class,'price') also matches price-was-struck-through and pricing-footer. When you need an exact class in a multi-class attribute, the idiomatic form is uglier and correct:

//*[contains(concat(' ',normalize-space(@class),' '),' price ')]

Text anchors

//button[normalize-space()='Add to cart']   exact text, whitespace-tolerant
//*[contains(text(),'Out of stock')]        substring within one text node
//*[contains(.,'Out of stock')]             substring anywhere in the subtree

The difference between the last two matters and catches everybody. text() is the element's own direct text node; . is the whole subtree as a string. If the words you want are wrapped in a nested span, text() will not see them and . will.

Axes, the thing CSS cannot do

//td[normalize-space()='Total']/following-sibling::td[1]     the cell after a label
//*[@id='sku-42']/ancestor::tr                              the row containing an element
//h2[normalize-space()='Specifications']/following::table[1] the first table after a heading
//*[@data-id='x']/parent::*                                 straight up one level

The label-then-value pattern in the first line is the most useful expression on this page. Specification tables, product attributes and invoice fields are all label-value pairs, and anchoring on the label rather than the position means the expression survives rows being added or reordered.

Predicates worth remembering

(//div[@class='item'])[1]        the first match document-wide, note the brackets
//div[@class='item'][1]          the first item within EACH parent, which is different
//a[@href and not(@rel)]         boolean logic in a predicate
//li[position() <= 3]            the first three of each set

The first two lines are the classic XPath mistake and they produce different results. Parenthesise the whole expression when you mean "the first one on the page".

How do you select an element by its text?

This is the row people search for by name, and there are three forms that behave differently.

The three forms

//span[text()='In stock']              exact match on a direct text node
//span[normalize-space()='In stock']   exact match, whitespace collapsed
//span[contains(.,'In stock')]         substring anywhere in the subtree

Why the first one fails constantly

Because HTML is full of whitespace you cannot see. A template that renders

<span>
  In stock
</span>

produces a text node of "\n In stock\n", and text()='In stock' does not match it. normalize-space() collapses runs of whitespace and trims the ends, which is why it should be your default rather than your fallback.

Why the third one over-matches

contains(.,'In stock') searches the entire subtree as a flattened string, so an ancestor div containing the whole product card also matches. You get the deepest match and every wrapper above it. Combine it with an element constraint or take the last match rather than the first.

The pattern that works

//*[normalize-space(text())='In stock']

Element-agnostic, whitespace-tolerant, and matching on the element's own text rather than its descendants'. That expression handles the large majority of text selection and is worth memorising as one unit.

The honest limit

Text anchors survive layout changes and break on copy edits. "In stock" becoming "Available now" is a content decision somebody makes without thinking about your scraper. If the page offers a data- attribute or structured data for the same fact, prefer it, and use text only when nothing else marks the thing you want.

The whitespace you cannot see is most of the problem

One more reason the durability table above puts text near the bottom. HTML whitespace is invented by templating engines and reformatters, not authored, so it changes when nobody touched the content. A build that switches from one formatter to another can reflow every text node on the site without a single copy edit, and every exact-match text expression on your side stops matching at once.

That failure arrives as empty results rather than errors, which is the recurring theme of this whole category: the expensive failures do not throw. The same shape appears in a crawl returning HTTP 200 with an empty body, described in Crawl4AI: When Should You Run Your Own Crawler?, and in a search parameter that silently stops working, in Google Search URL Parameters. Assert on what you extracted, not on whether the request succeeded.

A working order for writing one

Four steps, and doing them in order takes about two minutes per field.

Search the markup for the value you want rather than for its label, because the label is what you can see and the value is what carries the attributes. Check whether the element holding it has a data- attribute, an itemprop or a meaningful id; if it does, anchor there and stop. If it does not, find a nearby label you can anchor on and reach the value with following-sibling or ancestor. Only when neither exists should a class fragment enter the picture, and only when that fails should you match on text.

The order matters because each fallback is measurably more fragile than the one above it, and people reach for the bottom of the list first because it is the one that is easiest to see in the rendered page.

📖 See also Ingesting Mixed Documents for LLM Embedding: PDF to Markdown

Which endpoint should I use for which job?

Every row was verified with monid inspect on 2026-08-31. The table gives billing shape rather than figures; shape drives design and current numbers live on monid.ai/tools.

The row worth noticing is the second. A page's JSON-LD block frequently contains the price, the name, the rating and the availability as structured data the site publishes on purpose, and reading it needs no selector at all. Checking for it before writing XPath is the cheapest thirty seconds in this whole discipline.

When should you not be writing XPath at all?

Three cases, and the first is more common than it looks.

The page already publishes structured data. JSON-LD, microdata or an embedded state blob. Sites ship these for search engines and for their own front ends, and they are a documented contract in a way that markup is not. A scrape endpoint that returns the JSON-LD alongside the text hands you the fields without a single expression.

Somebody else maintains the parser. If a purpose-built endpoint covers your target, the selectors are their problem forever. That is the whole trade discussed in Web Scraping Tools: Which Kind Do You Actually Need?, and it is the right trade whenever the extraction is not itself your product.

You can describe the fields instead. An extract endpoint takes a JSON Schema and returns typed values, which moves the specification from "where the element sits" to "what the field means". That survives redesigns by construction, because nothing in the schema references the layout.

Where XPath remains the right answer: a site nobody has built for, markup with no structured data, extraction rules specific enough that they are part of your product, or a one-off pull where writing three expressions beats evaluating anything.

And the disclosure: you are reading Monid's blog and we sell extraction endpoints, so we have an interest in the third bullet. The dozen expressions above are still the right tool when you are writing them yourself, which is why they are on this page rather than a pitch.

Conclusion

A useful XPath reference is short, because the expressions worth memorising are the ones that survive somebody else's redesign. Anchor on attributes that were put there on purpose, use normalize-space() by default rather than as a fix, know that text() and . search different things, and parenthesise when you mean the first match on the page rather than the first within each parent.

The habit that matters more than any expression is checking what the page already publishes before writing a selector at all. A JSON-LD block gives you the price, the name and the availability as fields with names, and no redesign breaks it, because the site maintains it for its own reasons. The best XPath is frequently the one you did not have to write.

Free next step: fetch a page you were about to write selectors for and look at whether jsonLd came back populated. It costs a fraction of a cent and it settles in seconds whether you have a parsing job or a reading job. Start at monid.ai.

FAQ

Last updated August 2026.