CSS Selector Extractor

Opening an unfamiliar CSS file top to bottom is a poor way to understand it, because the structure that matters is not the order of the text but the set of things it targets. A selector list gives you that structure in one pass: which components the file owns, whether it reaches into markup it should not, how deeply it nests, and whether it repeats itself. Ten seconds with the list usually tells you more about whether a stylesheet is well-organised than ten minutes of scrolling.

A few patterns are worth acting on. The same selector appearing many times suggests rules that should be consolidated. Very long descendant chains indicate styles coupled to a specific DOM shape, which will break when the markup changes. Selectors combining IDs with classes point to past specificity fights. And a file whose selectors are all element names rather than classes is usually a global stylesheet that will surprise someone later. None of these is automatically wrong, but each is a reasonable place to look first.

To answer two questions quickly. First, what does this file target — which is what you need when you inherit a stylesheet, evaluate a third-party theme, or work out whether a file is safe to delete. Second, where are the conflicts: when the same selector appears several times in one file, the later rules are overriding the earlier ones, and that is where unexpected styling usually comes from. Source order matters for that, which is why the list preserves it rather than sorting.

Seeing the selectors together makes the shape of the problem visible. Long chains, repeated IDs, and selectors ending in !important are the signatures of a stylesheet where each fix has escalated the previous one, and they cluster around the components that are hardest to restyle. The list will not compute specificity scores for you, but it reliably shows you which parts of a file have become an arms race and therefore where a rewrite pays off most.

No — that requires knowing your markup, and this tool only reads the stylesheet. To find unused CSS, use the Coverage panel in Chrome devtools, which records which rules actually matched while you exercised the page. Treat its output as a starting point rather than a verdict: rules for states you did not trigger during recording, such as error messages or open modals, will look unused when they are not.

Yes. Selectors nested in @media, @supports, and similar at-rules appear in the list alongside top-level ones, in the order they occur. That is deliberate, because responsive overrides are a frequent source of the "why is this style not applying" question — and seeing a selector appear twice, once at the top level and once inside a breakpoint, is often the whole answer.

No. Every one of these tools runs entirely in your browser using JavaScript. Your stylesheet is never uploaded, never logged, and never sent to any server — you can confirm this by opening your browser devtools Network tab while you work, or by disconnecting from the internet after the page loads and watching everything continue to function. That makes it safe to paste proprietary or client CSS.