Sort CSS selectors by specificity

This tool accepts a list of individual CSS selectors, validates their syntax, calculates each three-part specificity value, and returns the entire list ordered from lowest to highest. It understands modern functional pseudo-classes such as :is(), :not(), :has(), :where(), and :nth-child(), while preserving the original order when two selectors have equal weight.

Read the three-part specificity score

Each result uses the familiar ID, class, and type structure. The first number counts ID selectors such as <code>#checkout</code>. The second counts classes, attribute selectors, and pseudo-classes such as <code>.active</code>, <code>[disabled]</code>, and <code>:hover</code>. The third counts type selectors and pseudo-elements such as <code>button</code> and <code>::before</code>. Universal selectors and combinators add nothing. Comparison is lexicographic, so one ID outweighs any number of entries in the other columns, and one class outweighs any number of type selectors when the ID counts match. The returned <code>specificity</code> array is convenient for software, while <code>specificity_text</code> gives the same value in a compact, readable form. Results are sorted ascending, which places broadly reusable rules first and the hardest selectors to override last. When two scores match exactly, the tool keeps their input order instead of inventing a secondary alphabetical ranking. That stable behavior makes repeated runs predictable and preserves useful context from a stylesheet or review checklist.

Handle modern pseudo-classes correctly

Functional pseudo-classes are where manual calculations most often go wrong. <code>:where()</code> always contributes zero specificity, including the selectors inside it, so authors can add structural precision without making a rule harder to override. By contrast, <code>:is()</code>, <code>:not()</code>, and <code>:has()</code> contribute the specificity of their most specific argument rather than adding a pseudo-class point of their own. The <code>:nth-child()</code> and <code>:nth-last-child()</code> forms contribute one pseudo-class point, plus the highest specificity in an optional <code>of</code> selector list. Shadow-tree forms such as <code>:host()</code> and <code>::slotted()</code> are also accounted for. The parser walks nested parentheses, brackets, quoted strings, and escapes, so commas inside a functional selector are not confused with commas separating top-level selectors. Supply each list item as one selector. A top-level comma would represent several selectors with potentially different scores, so it is rejected rather than collapsed into a misleading single value. This explicit rule keeps every input item mapped to exactly one output score.

Use the sorted list to simplify a cascade

A specificity report is most useful as a refactoring aid, not as encouragement to build stronger selectors. Paste representative selectors from a component, design system, or legacy stylesheet and inspect the high end of the result. Large jumps often reveal IDs, deeply qualified states, or a powerful argument hidden inside <code>:is()</code> or <code>:not()</code>. Those selectors may force later code to repeat structural details merely to override a declaration. Consider replacing them with a single-purpose class, lowering optional context with <code>:where()</code>, or organizing layers so precedence does not depend on escalating scores. The low end is useful too: element rules and lightweight utilities are easier to reuse when their intended role is clear. Automated pipelines can call the API for $0.002 to flag newly introduced selectors above a team-defined threshold, record specificity alongside generated CSS, or present ordered diagnostics during review. Invalid input fails the whole request, ensuring a partial report never hides a malformed selector that should be fixed first. The calculation is deterministic and requires no network access, so identical input always produces identical ordering and values.