XPath for beginners: finding data inside XML without parsing it by hand
By the Converterzilla Team
We build privacy-first PDF and image tools that run entirely in your browser. Our team has shipped JavaScript file-processing apps used by thousands every day, and we write here about the libraries, trade-offs and patterns we use.
XPath is a query language for navigating XML documents — the equivalent of a CSS selector, but for XML trees instead of HTML. Instead of writing a loop to walk through nested elements looking for the one you want, you write a path expression and get matching nodes back directly. It's a small language, and a handful of patterns cover the overwhelming majority of real-world use.
The core patterns
/root/child— an absolute path from the document root, matching a specific chain of element names.//item— any<item>element anywhere in the document, regardless of depth. The double slash is the one piece of syntax people reach for constantly.//item[@id="42"]— an<item>element with a specific attribute value. Square brackets are XPath's filter/predicate syntax.//item[3]— the third<item>among its siblings (XPath indexes from 1, not 0 — a common source of off-by-one confusion for anyone coming from most programming languages).//item/@id— not the element, but the value of itsidattribute directly.//*— every element in the document, useful as a first sanity check that your XPath engine is reading the file at all.
Attributes vs elements: the @ matters
The single most common XPath mistake: forgetting that attributes need an @ prefix. //item[id="42"] looks for a child element named id with that text content — completely different from //item[@id="42"], which checks the id attribute on the item element itself. If a query that should obviously match returns nothing, this is the first thing worth checking.
Testing before you commit code to it
XPath expressions that look right often aren't, especially once namespaces or deep nesting are involved — testing against real sample data before wiring an expression into a scraper or parser saves a debugging cycle later. Run the expression, look at what actually comes back, adjust.
Our XPath tester runs your expression against pasted or dropped XML using the browser's native XPath engine (the same evaluator real browsers use for XML processing) and shows exactly which nodes matched — a fast way to sanity-check a query before it goes into a script.