| Node | Depth | Matched |
|---|---|---|
| Run a selector to inspect the parsed DOM tree. | ||
Search Results |
||||||
|---|---|---|---|---|---|---|
| # | id | tagName | className | outerHTML | Suggested Selector | Robustness |
jQuery Selector Cheat Sheet — Click a row to apply the selector |
||
|---|---|---|
| Selector | Example $("pattern") | Notes |
| Basic | ||
| Wild Card | * | Returns ALL elements |
| Element | p | Returns all paragraph elements* <p>One</p> <p> Two</p> |
| ID | #MyID | Returns all elements with id of MyID: <div id="MyID"> </div> |
| Class | .MyClass | Returns all elements with css class of MyClass: <div class="MyClass"> </div> |
| Combinations | ||
| And | div, span | Returns all div AND span elements. The comma is the AND operator. |
| Child | div > span | Returns span elements directly inside a div. |
| Ancestor | div span | Returns all span elements inside a div. The space is the Ancestor operator. |
| Attributes | ||
| Attribute | [xyz] | Returns all elements with the attribute: <input xyz="abc" /> <div xyz="123" /> |
| Attribute Value | input[xyz=abc] | Returns all input elements with an attribute of xyz and value of abc: <input xyz="abc" /> |
| Attr$ | input[id$=abc] | Returns <input id="123abc" /> (ends with) |
| Attr^ | input[id^=abc] | Returns <input id="abc123" /> (starts with) |
| Attr* | input[id*=abc] | Returns <input id="123abc123" /> (contains) |
| Multiple | input[name=abc][value=yes] | Returns <input name="abc" value="yes" /> (both attributes/values present) |
| Missing | input:not([alt]) | Returns all input elements MISSING attribute alt |
| Misc | ||
| Checkbox | input[type=checkbox]:checked | Returns all checked checkboxes |
| Radio Button | input[type=radio]:not(:checked) | Returns all unchecked radio buttons |
| Selected | #MySelect :selected | Returns all Selected elements from element with id MySelect |
| Even items | #MyTable tr:even | Returns all even rows (can also use odd). Note: Even/Odd is zero based. |
| nth-child | #MyTable tr:nth-child(2) | Returns element by position, in this case the 2nd row in the table. Note: nth-position is 1 based. |
| Contains | p:contains("Hello") | Returns all paragraph elements that contain the text "Hello" |
| Lists | ||
| nth-child | li:nth-child(1) | Returns all li elements that are the first child of their parent |
| nth-child | li:nth-child(3) | Returns all li elements that are the third child of their parent |
| nth-child | li:nth-last-child(1) | Returns all li elements that are the first child of their parent, counting from the last li element |
This jQuery nested selector page is for front-end debugging tasks where you want to test a selector against known markup before you touch application code. Paste the HTML you care about, try a selector, and inspect what the expression actually matches.
That matters because nested selectors, attribute filters, and descendant chains often look correct until you run them on real markup. The practical value of the result is not just whether the selector is valid, but whether it targets the elements you intended instead of too many or too few.
A selector that worked before a template refactor now matches the wrong nodes. Pasting the current markup into the tester makes the mismatch easier to isolate.
You want to confirm whether a selector built around data attributes is specific enough before you rely on it in a script or test harness.
Selector testing becomes even more reliable when you keep a minimal HTML sample that reproduces the bug instead of pasting a huge page fragment every time. Smaller markup makes it easier to see why a selector is overreaching, why a descendant chain is too loose, or why a reused class name is matching more elements than expected. That lightweight sample is often more useful during debugging than trying to reason about a full production DOM in one pass.
Once the selector looks right in isolation, confirm it in the real browser context where scripts, generated markup, and hidden wrapper elements may still affect the result. The page is most valuable when it shortens the path to that real verification step, not when it replaces it.
It is best for checking whether a selector matches the intended elements against known markup before you edit live code.
No. It is a focused selector check, not a full runtime DOM inspector. It is most useful early in debugging or when you only have copied markup.
Live pages may include JavaScript-generated markup, hidden wrappers, or dynamic state that was not present in the snippet you tested.
A final habit that pays off across these workflows is keeping the original source data nearby while you review the transformed output. When the browser result looks cleaner or easier to read, it becomes much easier to spot whether the real issue was syntax, structure, ordering, or a bad assumption about the payload itself.
After the selector is stable, move into the wider debugging context where it will actually run. That is why Keyboard Tester can be a sensible follow-up when your front-end troubleshooting expands beyond selector syntax.
A good workflow is to prove the selector against clean markup first, then confirm it in the real page or test harness that will execute it.
Fix the cause, not the symptom.
…
…