CSS Selector Cheat Sheet for Web Scraping (2026)

You’re probably here because a scraper that worked yesterday is returning empty rows today.

The request still succeeds. The page still loads in your browser. But the selector that used to pull the product title, price, author name, or review count now matches nothing, or worse, matches the wrong thing. That’s the recurring tax of scraping modern sites. Most failures aren’t networking failures. They’re selector failures.

A good css selector cheat sheet isn’t just a syntax list. For scraping, it’s a survival guide. You need selectors that are precise enough to pull the right data, flexible enough to survive layout changes, and readable enough that someone else on your team can debug them fast.

Why Master CSS Selectors for Data Extraction

CSS selectors started as a web styling tool in the mid-1990s, but their precision made them central to data extraction as well, especially when you need to target exact nodes like .price-current, author names, or navigation links in HTML documents, as noted in the freeCodeCamp CSS selectors cheat sheet. That shift matters because scraping is really a targeting problem. If you can’t consistently target the right element, nothing else in the pipeline matters.

In production scraping, selector skill shows up in three places.

Reliability: A weak selector breaks as soon as a site adds one wrapper div or reuses a class name elsewhere.

Maintainability: A clean selector tells your team what it’s intended to extract.

Efficiency: Querying the DOM with a direct selector is cleaner than manually walking a large HTML tree.

What trips up new scrapers is thinking of selectors as a front-end concern. They’re not. In extraction work, selectors are your query language for HTML.

The best selectors aren’t always the shortest ones. They’re the ones that express stable intent. A selector such as .product-card .price-current says much more than .price-current alone. It anchors the value to a local context, which is exactly what you need when pages repeat UI patterns.

That’s also why scrapers rely on CSS selectors so heavily across e-commerce monitoring, content aggregation, and SEO intelligence workflows. The same capabilities that let designers style a page let data engineers extract structured fields with surgical precision. When you master selectors, your scraper stops guessing and starts targeting.

The 60 Second CSS Selector Quick Reference

When you need a fast lookup, use this as your working shortlist. These are the selectors that carry most scraping tasks.

Selector Type	Syntax Example	Targets
Element	`a`	All `<a>` tags
Class	`.product-title`	Any element with class `product-title`
ID	`#main-content`	The element with ID `main-content`
Attribute present	`[href]`	Any element that has an `href` attribute
Attribute exact match	`[type="submit"]`	Elements whose `type` is exactly `submit`
Descendant	`.card .price`	Any `.price` inside `.card`
Child	`.card > .price`	`.price` elements that are direct children of `.card`
Adjacent sibling	`h2 + p`	The first `<p>` immediately after an `<h2>`
General sibling	`h2 ~ p`	All `<p>` siblings that follow an `<h2>`
Grouping	`h1, h2, h3`	All matching headings
First child	`li:first-child`	The first list item in each list
Nth child	`tr:nth-child(2)`	The second row in each table section

A quick reference only helps if you know when to stop using it. If a selector works in one DOM snapshot but fails across repeated cards, pagination states, or rendered content, it needs context, not memorization.

Fundamental Selectors The Building Blocks

Every strong scraper rests on a small set of selector primitives. If these aren’t second nature, complex selectors will feel random.

Type class and ID selectors

A type selector matches by tag name.


<div>One</div>
<div>Two</div>
<span>Three</span>

Selector:

div

This matches both <div> elements. In scraping, type selectors alone are usually too broad, but they become useful when paired with classes or structure.

A class selector starts with a dot.


<h2 class="product-title">Keyboard</h2>
<h2 class="product-title">Mouse</h2>

Selector:


.product-title

This is one of the most common scraping selectors because classes often reflect UI meaning, even when the markup is messy.

An ID selector starts with #.


<section id="main-content">
  ...
</section>

Selector:


#main-content

IDs can be excellent anchors when they’re stable. They’re less useful when sites generate them dynamically.

Universal and grouping selectors

The universal selector is *. It matches everything.

For scraping, this isn’t a practical extraction selector. It’s mainly useful in debugging or when narrowing from an already scoped parent selection.

The grouping selector uses commas.


h1, h2, h3

That lets you fetch several related elements with one query. It’s handy when headings vary across templates.

Here’s the rule that matters in real parsing work:

Use type selectors when the tag itself is meaningful

Use class selectors when the UI exposes stable semantics

Use IDs as anchors, not as a crutch

Use grouping when templates vary

Avoid universal selectors for extraction logic

If you spend a lot of time debugging malformed HTML, it helps to understand how parsers normalize broken markup before your selector ever runs. The HTML parsing discussions on Scrappey Q&A are useful for those edge cases.

Combinators Targeting Elements by Relationship

Most scraping targets don’t have unique classes. They’re identifiable because of where they sit in the DOM. That’s where combinators earn their keep.

Descendant and child combinators

The descendant combinator is a space.


<div class="product-card">
  <div class="details">
    <span class="price">$19</span>
  </div>
</div>

Selector:


.product-card .price

This matches any .price anywhere inside .product-card, no matter how nested.

The child combinator is >.


.product-card > .price

That only matches .price if it is a direct child of .product-card.

Use descendant selectors when the page adds wrapper layers unpredictably. Use child selectors when you need stricter control and you know the structure is stable.

Adjacent and general sibling combinators

The adjacent sibling combinator is +.


<h2>Specifications</h2>
<p>Aluminum body</p>
<p>Backlit keys</p>

Selector:


h2 + p

This matches only the first <p> immediately after h2.

The general sibling combinator is ~.


h2 ~ p

This matches every following <p> sibling after the h2, as long as they share the same parent.

That distinction matters when content blocks are loosely structured. Adjacent sibling is tighter. General sibling is broader.

What works in scraping

Combinators are how you add context without depending on brittle auto-generated class names.

Descendant selectors work well for cards, repeated modules, and nested content.

Child selectors work when wrapper depth is meaningful and stable.

Adjacent sibling selectors help with label-value layouts.

General sibling selectors help when a heading introduces a whole content block.

A lot of bad selectors fail because they ignore relationship. If ten prices exist on the page, .price isn’t a selector strategy. .product-card .price is.

Attribute Selectors Unlocking Data from HTML Tags

When classes are useless, attributes often save the scrape.

That happens all the time on modern sites. Class names may be hashed, duplicated, or tied to styling systems that change often. But attributes like href, src, type, aria-label, and data-* frequently carry more stable meaning.

Presence and exact match

The simplest attribute selector checks whether an attribute exists.


<a href="/products/1">View</a>
<a>Broken link</a>

Selector:


a[href]

This matches only anchors that have an href. For scraping, that’s a clean way to avoid placeholders or JavaScript-only elements.

Exact match is just as useful.


<input type="submit" value="Buy now">
<input type="text" name="email">

Selector:


input[type="submit"]

That’s especially helpful when forms use generic classes but meaningful attributes.

Partial matching patterns

Partial match selectors are where scraping gets practical.

Selector	Meaning	Example use
`[class^="product-"]`	Starts with	Find classes using a naming prefix
`[src$=".jpg"]`	Ends with	Find image URLs with a given file suffix
`[class*="-active"]`	Contains substring	Match stateful classes
`[rel~="nofollow"]`	Contains word	Match tokenized attribute values

Example:


<div class="product-card featured"></div>
<div class="product-badge sale"></div>

Selector:


[class^="product-"]

This matches both elements because each class attribute starts with product-.

For media extraction:


<img src="/images/item-1.jpg">
<img src="/icons/cart.svg">

Selector:


img[src$=".jpg"]

That narrows the candidate set fast.

Data attributes and accessibility attributes

For scrapers, data-* attributes are often gold.


<button data-testid="add-to-cart">Add</button>
<span data-sku="ABC123">In stock</span>

Selectors:


[data-testid="add-to-cart"]
[data-sku]

These tend to be more intentional than styling classes because teams use them for testing, instrumentation, or application state.

Accessibility attributes can also be surprisingly stable:


button[aria-label="Search"]

That said, don’t blindly trust attribute values either. Product IDs, tracking parameters, and session-related attributes can rotate.

Good attribute selector habits:

Prefer semantic attributes like data-testid, data-sku, aria-label, and href

Use partial matches carefully because they can overmatch

Avoid binding to random hashes embedded in class or data values

Combine with local context when the page repeats patterns

If the page won’t give you a stable class, attributes usually offer a second path.

Pseudo-Classes Targeting by State and Structure

Pseudo-classes let you target elements by condition or position rather than by plain tag or attribute. For scraping, the structural ones matter far more than the interactive ones, but both are worth understanding.

State based pseudo-classes

Selectors like :hover, :focus, and :visited describe user interaction or browser state.


a:hover
input:focus
a:visited

In static HTML parsing, these usually don’t help much because your parser sees markup, not a live user session. In rendered browser automation, they become relevant if JavaScript changes the DOM in response to interaction.

If a menu reveals hidden links only after hover, the pseudo-class itself doesn’t magically extract that state. You still need to trigger the interaction in a browser context and inspect the resulting DOM.

So the practical lesson is simple. State pseudo-classes are useful for understanding front-end behavior, but they’re not usually your primary scraping selectors.

Structural pseudo-classes

Structural pseudo-classes are much more valuable.


<ul>
  <li>First</li>
  <li>Second</li>
  <li>Third</li>
</ul>

Selectors:


li:first-child
li:last-child

These match the first and last list items respectively.

Other useful ones:

:only-child matches an element that is the sole child of its parent

:empty matches elements with no child nodes or text

:first-of-type and :last-of-type target by tag type, not just position

Example:


<div>
  <h3>Title</h3>
  <p>Summary</p>
  <p>Details</p>
</div>


p:first-of-type

This matches the first paragraph, not the first child overall.

Where scrapers use them well

Pseudo-classes help when repeated structures don’t expose enough semantic markup.

Lists: li:first-child for featured items

Tables: tr:first-child when headers are rendered as rows

Cards: .badge:empty to detect missing labels

Content blocks: p:last-child when summaries and footnotes share a wrapper

The trap is overusing positional logic where a better semantic selector exists. A page redesign can reorder children and break :first-child instantly, while a stable class or data attribute survives.

Use pseudo-classes when structure is the strongest available signal. Don’t use them just because they look clever.

Advanced Targeting with nth-child and Pseudo-Elements

Many selectors become either powerful or fragile depending on this.

nth-child() is excellent when the DOM has a repeatable pattern. It’s terrible when you’re using it to compensate for poor understanding of the page structure.

Getting nth-child right

Basic examples first:


li:nth-child(1)
li:nth-child(2)

These match the first and second child elements.

You can also use keywords:


li:nth-child(odd)
li:nth-child(even)

And formulas:


li:nth-child(3n)
li:nth-child(3n+1)

3n means every third element. 3n+1 means the first element in each repeating group of three.

Example HTML:


<ul>
  <li>A</li>
  <li>B</li>
  <li>C</li>
  <li>D</li>
  <li>E</li>
  <li>F</li>
</ul>

li:nth-child(3n) matches C and F

li:nth-child(odd) matches A, C, E

li:nth-child(n+2) matches everything except the first item

That last pattern is useful in tables when you want to skip the header row:


tr:nth-child(n+2)

nth-child versus nth-of-type

This is the distinction people miss.

nth-child() counts all element types among siblings.nth-of-type() counts only siblings of the same tag name.

Example:


<div>
  <h2>Title</h2>
  <p>Intro</p>
  <p>Body</p>
</div>


p:nth-child(2)

This matches the first <p> because it is the second child overall.


p:nth-of-type(2)

This matches the second <p> because it is the second paragraph among paragraph siblings.

For scraping, nth-of-type() is often safer when mixed tags appear in the same container.

Pseudo-elements in scraping

Pseudo-elements like ::before and ::after represent generated content in CSS, not normal DOM nodes.


.price::before
.note::after

If a site visually adds symbols or labels through CSS generated content, your HTML parser usually won’t see them as ordinary text nodes. Browser automation may expose computed content in some workflows, but this is not a first-line extraction strategy.

There are also non-standard parsing extensions in some scraping libraries, such as ::text or ::attr(), but support depends on the tool, not on CSS itself. Treat those as parser-specific features rather than universal browser selectors.

A practical rule for nth-* selectors:

Use them when the pattern is deliberate

Avoid them when the pattern is accidental

Prefer semantic anchors over raw position

Choose nth-of-type() when sibling tags vary

Understanding Selector Specificity to Avoid Bugs

Specificity is the browser’s way of deciding which selector has more weight when multiple selectors could match the same element. In scraping, the concept matters because it explains why some auto-generated selectors are overly heavy and why some simpler selectors are easier to maintain.

The scoring model that matters

Think of specificity as tiers.

Level	Examples	Relative strength
Universal, type, pseudo-elements	`*`, `div`, `::before`	Low
Classes, attributes, pseudo-classes	`.card`, `[href]`, `:first-child`	Medium
IDs	`#main`	High
Inline styles	`style=""` on element	Very high

The practical hierarchy above is the one to remember. An ID beats a class-based selector. A class-based selector beats a plain element selector.

So:


div.content

loses to


div#main.content

because the second selector includes an ID.

Why scrapers should care

Scrapers don’t usually fight CSS rules directly, but specificity still affects your workflow in two ways.

First, browser-generated selectors copied from DevTools are often too specific. They include IDs, child chains, and positional selectors that happen to identify the clicked node in that exact DOM snapshot. That doesn’t make them resilient.

Second, specificity helps you reason about selector intent. A selector with moderate specificity, tied to stable local context, is usually the sweet spot. Too broad and you get false positives. Too specific and one layout tweak breaks the scrape.

Use this debugging checklist when a selector behaves strangely:

Check scope first: Are you selecting globally when you should select within a parent node?

Inspect repetition: Does the class appear in headers, sidebars, and footers too?

Reduce noise: Remove unnecessary wrappers and nth-child() segments

Test alternatives: A simpler selector often reveals the stable anchor

Specificity isn’t just a CSS topic. It’s a discipline for writing selectors that express exactly enough.

Writing Robust Selectors That Do Not Break

A selector can be valid, precise, and still be a bad production choice.

The strongest scrapers are built on selectors that reflect stable page meaning, not temporary front-end implementation details. According to Scrapfly’s CSS selector scraping best practices, CSS selectors are often preferred over XPath for readability and performance, and a standard workflow is to validate selectors directly in browser DevTools with Cmd or Ctrl plus F in the Elements panel before deployment. That same guidance also points to a habit that saves a lot of cleanup later: use a contextual selector like .product-card .price instead of a broad selector like .price to reduce false positives.

What breaks first

These patterns fail constantly:

Auto-generated classes: .ax-j239f-a2s looks unique until the next build.

Long descendant chains: div > div > div > span.price depends on layout, not meaning.

Pure positional selectors: li:nth-child(4) assumes order will never shift.

Global selectors with common names: .title, .price, .button overmatch quickly.

If the site uses JavaScript to mutate the DOM after load, you may also need to trigger interactions before your target exists. For those cases, the guide to executing JavaScript during scraping is useful because selector reliability starts with getting the right DOM state, not just writing better syntax.

The production checklist

Use this when choosing selectors for real jobs:

Start from stable meaningPrefer data-*, semantic classes, IDs used as anchors, and meaningful attributes like href or aria-label.

Add local context.product-card .price is usually safer than .price.article h2 is usually safer than h2.

Keep chains shortIf a selector needs many levels to work, the page probably offers a better anchor somewhere closer to the target.

Test against multiple instancesDon’t test against only the first card. Test against all cards, edge cases, and alternate layouts.

Check rendered HTML, not just source HTMLMany failures come from selecting against the wrong DOM snapshot.

Reliable selectors don’t try to describe the whole page. They identify the smallest stable truth about the data you want.

Practical Scraping with Scrappey and Rendered HTML

Most selector problems aren’t selector problems. They’re DOM timing problems.

You inspect the page source, build a clean selector, and your extraction still returns nothing because the actual data only appears after JavaScript runs. In that case, the correct workflow starts with rendered HTML.

A practical workflow that holds up

Use this sequence on dynamic pages:

Load the page in a real browserOpen DevTools and inspect the actual rendered element, not the initial HTML response.

Test the selector in the Elements panelUse Cmd or Ctrl plus F to confirm it matches the intended nodes in the rendered DOM.

Wait for the target before extractionOn pages with delayed rendering, use a wait condition tied to a stable selector. The Scrappey wait for selector documentation is the right pattern for this.

Extract from the final DOMOnce the page has rendered the target data, your selector can do real work.

Here’s the sort of target you want:


.product-card [data-testid="price"]

Here’s the sort of target you should distrust:


#root > div > main > section:nth-child(2) > div > article > span

The second one may match today. It won’t age well.

Choosing CSS selectors in real jobs

For most scraping tasks, CSS selectors are the first choice when the page offers good structure and stable attributes. They’re readable, concise, and easy to validate in the browser.

Choose XPath when you need something CSS can’t express well, such as selecting by text content, navigating upward to a parent, or building more complex conditional logic. Don’t force CSS into jobs where XPath is the cleaner fit.

There’s also an operational side to this. When you scrape dynamic pages at scale, rendering and retries can create bursty request patterns. If you’re tuning collection workflows around those constraints, the API rate limit guide for traders is a useful read because the same rate-management discipline applies to scraping systems that need predictable throughput.

A final practical note on selector syntax: if class names contain special characters, you may need to escape them in CSS. In many cases, though, it’s cleaner to bypass awkward class names altogether and target a nearby stable attribute or container relationship instead.

Frequently Asked Questions about CSS Selectors

Can CSS selectors target text content

Not in standard CSS selector syntax. If you need to match an element based on visible text, XPath is usually the better fit. Some parsing libraries add non-standard helpers, but those are tool-specific.

Are CSS selectors case-sensitive

It depends on the document type and the selector component. In HTML, tag names are generally treated case-insensitively by browsers. Attribute handling can vary by context, so test against the parser you use in production.

Can CSS selectors reach parent elements

Standard CSS selectors don’t traverse upward to parents or ancestors in the general way XPath can. If your extraction logic depends on climbing the DOM, switch tools rather than forcing a brittle workaround.

What about Shadow DOM

Regular selectors won’t automatically pierce closed Shadow DOM boundaries. In browser automation, you usually need explicit access to the shadow root before running selectors inside it.

When should I use XPath instead

Use XPath when you need parent traversal, text matching, or more expressive logical conditions. Use CSS selectors when the page has stable classes, attributes, and straightforward parent-to-child navigation.

Why does a selector work in DevTools but fail in code

Usually one of three reasons:

Wrong DOM state: Your code parses the initial response, while DevTools shows rendered content.

Timing issue: The target appears after JavaScript finishes.

Parser differences: Browser selector behavior and server-side parser behavior don’t always match perfectly.

A good css selector cheat sheet helps, but reliable scraping comes from combining selector skill with the right DOM, the right timing, and the right extraction tool.

If you need a platform that handles rendered pages, dynamic content, and large-scale extraction without making your team babysit browser infrastructure, Scrappey is worth a look. It’s built for developers who need dependable web data pipelines, not just one-off scripts.