Copyright © 2025 ScriptNG
Designed by ScriptNG
Writing XPath and CSS Selectors in Selenium: Ultimate Guide
Master XPath and CSS Selectors — No More Flaky Tests, Ever.
😤 The Day XPath Broke Me
Let me tell you a quick story. It was a Friday evening (because of course), I was packing up, dreaming about chicken biryani, and suddenly my lead goes:
“Hey, the login test is failing. Again.”
I opened the script. The XPath that was perfectly fine yesterday was now returning nothing. Nada. Just a big, fat void.
Turns out the dev had wrapped the login button in another <div> for styling—and boom, my fragile little /html/body/... XPath exploded.
I ended up spending 2 hours rewriting locators and rage-Googling “best practices in XPath” while sipping cold tea.
Moral of the story? XPath is powerful. But also extremely breakable if you don’t write it with foresight.
⚔️ CSS vs XPath: Choose Your Fighter
Ah yes, the age-old debate. CSS or XPath?
🧪 CSS Selector: The Sleek Assassin
- Fast AF — Native to browsers, minimal parsing.
- Cleaner syntax — Feels like poetry compared to verbose XPath.
- Great for static pages.
⚙️ XPath: The Swiss Army Knife
- Super flexible — Can traverse up, down, sideways in DOM.
- Text-based search — Handy for finding dynamic elements.
- Supports complex conditions.
My take?
Use CSS when you can, switch to XPath when you must.
Use CSS when you can, switch to XPath when you must.
🎯 How XPath and CSS Selectors in Selenium Work
| Use Case | Use CSS | Use XPath |
|---|---|---|
|
Finding elements by class, ID, attribute |
✅ |
✅ |
|
Selecting based on visible text |
❌ |
✅ |
|
Navigating siblings or parents |
❌ |
✅ |
|
Performance-critical tests |
✅ |
❌ |
|
React/Angular dynamic apps |
✅(with data-* attributes) |
✅(for fallback) |
|
Shadow DOM or iframe access |
❌(unless JS hack used) |
❌(need JS execution) |
🧬 How to Write Kickass Selectors
📌 Basic XPath Syntax Cheatsheet
//tagname[@attribute='value']
//div[@id='login']
//input[contains(@name, 'email')]
//a[text()='Click me']
//ul/li[3]/a
//div[@class='user-card']//span[contains(text(), 'Admin')]
Bonus: Use normalize-space() to trim whitespaces in text.
🎯 Basic CSS Selector Cheatsheet
tag[attribute="value"]
div#login
input[name*="email"]
a[href$=".pdf"]
ul li:nth-child(3) a
.form-section > .input-wrapper > input[type="text"]
⚠️ Reminder: CSS can’t match text content directly (no :contains() in vanilla CSS).
🔍 Real-World Examples That Will Save You
✅ Good
//button[normalize-space()='Login']
❌ Bad
/html/body/div[2]/div[1]/div[3]/form/button[1]
✅ CSS
input[name^="user_"]
❌ CSS
div > div > div > div:nth-child(5) > span
🤕 The Good, The Bad, and The Ugly
| Type | Example | Why It Works / Fails |
|---|---|---|
|
Good XPath |
//input[@placeholder=’Email’] |
Resilient, attribute-based |
|
Bad XPath |
/html/body/div[3]/table/tr[2] |
DOM fragile, unreadable |
|
Ugly CSS |
#root > div > form > div:nth-child(4) |
Brittle with every layout tweak |
|
Great CSS |
.login-form .email-input |
Scalable and readable |
🧾 Selector Templates You’ll Use Forever
✅ XPath Templates
| Use Case | XPath |
|---|---|
| By text | //a[text()='Register'] |
| Partial attribute | //*[contains(@id, 'user_')] |
| Starts-with match | //*[starts-with(@name, 'email_')] |
| Sibling navigation | //label[text()='Email']/following-sibling::input |
| With multiple attributes | //input[@type='text' and @name='user'] |
✅ CSS Templates
| Use Case | CSS |
|---|---|
| By ID | #submitBtn |
| By class | .product-card |
| Attribute match | input[placeholder='Search'] |
| Partial attribute | a[href*='profile'] |
| Multiple classes | .menu.nav-item.active |
⚛️ XPath and CSS in Angular/React Projects
React, Angular, Vue — these are Selector Hell if not handled right.
🙌 Pro Tips:
- Ask devs to add
data-testidordata-qaattributes - Avoid dynamic class names (e.g.,
sc-jibxUB) - Avoid absolute paths — framework renders change often
Example:
xpath
//*[@data-testid='login-button']
css
button[data-qa="submit"]
Wait—I almost forgot… don’t try to match by visible text in React using CSS. It’s a waste of time.
🔍 Top Debugging Techniques
In Chrome DevTools:
- For XPath:
$x('//button[text()="Login"]') - For CSS:
$$('button.login-btn')
Quick Checklist:
- ❓ Is the element inside an iframe? → Use
driver.switchTo().frame() - ❓ Is it hidden? → Check with
.isDisplayed() - ❓ Is it dynamic? → Use WebDriverWait and conditions
This reminds me of that one time I wrote a flawless XPath… but forgot to wait for the page to load. Spent 45 minutes blaming the dev. Sigh.
✅ Do’s and ❌ Don’ts
✅ Do’s
- Use short, meaningful locators
- Leverage
data-*attributes - Prefer relative over absolute XPath
- Maintain a central locator repository (yes, seriously)
❌ Don’ts
- Don’t hardcode deep-nested paths
- Don’t use auto-generated locators blindly
- Don’t ignore browser DevTools — they’re your best friend
- Don’t go selector-happy and overengineer it
FAQs
It depends on the situation. Use CSS selectors when possible — they’re faster and more readable. But if you need to traverse siblings, search by text, or do complex matching, XPath is your best bet.
Right-click the element → Inspect → Right-click in Elements tab → Copy → Copy XPath.
But wait—don’t just paste that thing into your code! Clean it up first. Chrome’s auto-generated XPaths are often absolute (a.k.a. brittle garbage).
Yes, of course! Use whatever gets the job done. I often mix them depending on which selector is more reliable for a specific element.
Ah, the classic “it-works-there” mystery. Likely causes:
- The element isn’t visible yet → try waiting.
- It’s inside an iframe → switch to it first.
- You copied an absolute XPath that broke.
Use:
contains()orstarts-with()in XPathPartial attribute selectors like
[id*='login']in CSS
Or, ask devs to add adata-testid— your future self will thank you.
Yes, slightly. XPath requires more parsing and isn’t native to browsers like CSS. But unless you’re automating a huge DOM tree, the difference is usually negligible.
/= absolute path (starts from root)//= relative path (starts anywhere)
Pro tip: Always prefer // unless you’re intentionally going absolute.
Yes, and that’s one of its superpowers.
Example: //button[text()='Submit']
CSS selectors can’t do this — not even with coffee.
Use data-testid, data-qa, or other custom attributes. Avoid depending on dynamic class names like sc-hGFkgZ — they’ll break often.
Example:
Maintain a separate locator file or class (e.g., in Page Object Model). It makes maintenance a breeze when things break — and trust me, they will break.
Yes. Tools like:
ChroPath (Chrome extension)
SelectorsHub
They suggest smarter, relative selectors. Still — double-check before using them blindly.
You can always check the official Selenium documentation on locating elements. It’s not the funniest read, but it’s solid and up-to-date.
🚫 Avoid:
Long absolute paths like
/html/body/div[4]/form/table/tr[2]/tdRelying on temporary class names
Using indexes unless necessary (like
div[3])
Go for attribute-based, relative, and resilient selectors.
This usually points to browser-specific rendering differences or visibility issues. Also check for:
Shadow DOM
Dynamic loading
Browser drivers out of sync
Use explicit waits or visibility checks.
Not directly. XPath 1.0 (which Selenium uses) doesn’t support full regex. But you can mimic basic behavior with contains() or starts-with().
😡 Last Words (and a rant)
You know what’s worse than flaky selectors?
Flaky selectors in flaky environments with flaky developers who change IDs at 11 PM.
I once had a test suite that worked perfectly for weeks. Then the team upgraded the frontend framework — and all class names changed.
No warning. No mercy. My selectors turned into confetti.
Here’s the thing:
- Selectors are your foundation.
- Don’t copy-paste garbage from DevTools.
- Don’t trust auto-generated junk.
- Build selectors like you’ll debug them at 3AM.
💥 Call to Action
🔥 Have a worst selector horror story? Drop it in the comments.
📌 Bookmark this guide. You’ll need it.
🤜 Still using absolute XPaths? We need to talk.
Also Don’t forget to check our blogs.
One Response