You inherit a 12,000-line stylesheet and want to delete the rules nothing uses. How do you identify dead CSS, and why do coverage reports and automated purge tools over-report rules as unused?

## Why CSS has no compiler to tell you In most languages, deleting an unused function is safe because the build fails if you were wrong. CSS offers no such feedback. A selector that matches no element is not an error, not a warning, and not observable at runtime — it simply never applies. The link between a rule and the markup it styles is a string comparison performed by the browser against a DOM that may not exist yet, may be assembled by JavaScript, or may come from a CMS field a developer has never seen. That is the whole difficulty. Everything below is about accumulating enough evidence to make deletion an acceptable risk, because certainty is not available. ## What coverage tooling actually measures Chrome DevTools has a **Coverage** panel: start recording, use the page, stop, and it reports how many bytes of each CSS file went unused. It is genuinely useful and routinely misread, because it answers a narrow question — *which rules did not apply during this recording* — and people hear *which rules are dead*. Things that count as unused in a normal recording but are very much alive: - `:hover`, `:focus-visible`, `:active` rules for anything you did not interact with - state classes applied only on error, loading, or empty results - rules inside a `@media` block whose condition did not match your viewport - `@media print` rules - everything on the pages and routes you did not visit Coverage is a *starting list*, best used across a scripted walkthrough of many routes and viewports, and even then only to nominate candidates. ## Why purge tools over-report PurgeCSS, UnCSS and their equivalents take a different approach: they read your content files (templates, JSX, markdown) and extract every string token that could plausibly be a class name, then delete rules whose selectors reference tokens they never saw. This scales far better than a browser recording — but it is a text search, and text search cannot see a class name that does not exist as a literal: ```javascript // invisible to a content scanner: no literal "btn--danger" exists anywhere el.className = `btn--${variant}`; ``` The same blind spot covers class names supplied by a CMS or rich-text field, injected by a third-party widget, produced by server-rendered templates in another repository, or built from a lookup table. Every purge tool therefore ships a **safelist** escape hatch — and a safelist is an admission that the tool cannot decide. Teams that use one seriously write class names as complete literals (a lookup object mapping `variant` to the full class string) precisely so the scanner can see them. ## A safe deletion procedure 1. **Generate candidates** from coverage across a scripted route walkthrough, or from a purge tool run in report-only mode. Do not let either delete anything directly. 2. **Verify each candidate by searching the whole codebase** for the class token — not just the app's templates, but tests, email templates, documentation, seeded CMS content, and any sibling repository that renders the same markup. A single hit is enough to keep the rule; zero hits is *evidence*, not proof. 3. **Prefer deleting files over deleting rules.** If a component is gone, its whole stylesheet goes, and that decision is reviewable in a way that "removed 340 scattered rules" never is. 4. **Delete in small, per-area commits.** The value is revert granularity: when something breaks three weeks later, you want to undo one commit, not bisect a 4,000-line removal. 5. **Put visual regression behind it.** Screenshot diffs across the main routes and both themes catch the class of mistake that review does not — a rule nobody remembered was load-bearing. 6. **Watch the sheet size trend**, not a single audit. If the number goes down once and then resumes climbing, you fixed a symptom. ## Preventing the next 12,000 lines The reason the file got this big is structural: rules outlived what they styled because their file did not. The durable fix is colocation — a component's CSS in the component's file, so removing the feature removes the CSS as a side effect and nobody has to prove anything. Pair that with keeping literal class names literal, so whatever purge tool you adopt can actually see them, and the archaeology becomes a one-time cost rather than a recurring one.