Unused CSS Finder & Purge Tool
Scan web pages or pasted markup to detect unreferenced CSS selectors, measure dead stylesheet bloat, and generate clean purged CSS.
<style> blocks within the fetched HTML — it does not download or parse externally linked stylesheets (<link rel="stylesheet" href="...">), which is how most WordPress themes and page builders actually deliver their CSS. If a page has no inline <style> content, this tool cannot analyze its real stylesheet. For a genuine unused-CSS audit of an external stylesheet, paste both the page HTML and the full stylesheet CSS using the "Paste HTML & CSS" tab above.Technical Deep-Dive: Eliminating Unused CSS
📌 On this page
1. Why WordPress sites accumulate unused CSS
Most WordPress themes and page builders ship a single monolithic stylesheet containing rules for every widget, layout option, and component the theme supports — regardless of which ones a given page actually uses. A theme might support 40 different widget layouts, but any single page typically uses only 3-5 of them; the other 35-37 sets of rules are downloaded, parsed, and held in memory for nothing. Page builders like Elementor and Divi compound this by adding their own large core stylesheets on top of the active theme's CSS, and popular plugins (WooCommerce, contact forms, sliders) each contribute their own stylesheet regardless of whether their functionality appears on the current page.
2. How the CSSOM affects render performance
Before a browser can paint anything to the screen, it must parse every byte of CSS delivered to the page and build the CSS Object Model (CSSOM) — a complete in-memory representation of every rule, regardless of whether that rule ends up matching any element on the page. CSS is also render-blocking by default: the browser will not begin painting until CSSOM construction completes, meaning a large, mostly-unused stylesheet directly delays First Contentful Paint even though 80-90% of its rules will never apply to a single element on that page.
3. This tool's scope: inline styles, not external files
It's worth being explicit about this tool's actual capability: the live URL scan mode only extracts and analyzes CSS found inside inline <style> tags in the fetched HTML document. It does not fetch external stylesheet files referenced by <link rel="stylesheet"> tags — which is where the overwhelming majority of a typical WordPress page's CSS actually lives. When a scanned page has no inline styles, the tool clearly discloses this and falls back to a labeled sample dataset rather than silently reporting empty or misleading results. For a genuine audit of your theme's real stylesheet, use the "Paste HTML & CSS" tab and supply both directly — most themes expose their compiled CSS file content by viewing the page source's stylesheet link and opening that URL directly.
4. Why naive class-name matching has limits
Real CSS unused-code detection tools like PurgeCSS or UnCSS parse the actual DOM tree and evaluate full CSS selector logic (including descendant combinators, pseudo-classes, and attribute selectors) against it. This tool uses a lighter-weight, transparent heuristic instead: it extracts the class or ID token from a selector and checks whether that literal string appears anywhere in the provided HTML text. This correctly handles the common case (a simple class selector matching a class attribute) but does not evaluate compound selectors precisely — for instance, .card.featured requires both class tokens to independently appear in the HTML, which is usually but not always equivalent to true DOM matching.
5. Safelisting: protecting dynamically added classes
Any class that JavaScript adds to an element after the initial page load — .is-active on a clicked accordion, .modal-open on the <body> when a popup opens, .dropdown-show on an expanded menu — will not appear anywhere in the raw server-rendered HTML this tool analyzes, since it only exists after user interaction triggers a script. A rule matched against such a class will always be flagged as "unused" even though it is essential. Any real CSS purging workflow (whether using this tool's output or a dedicated build-time tool like PurgeCSS) must maintain an explicit safelist of these interaction-driven class names to avoid breaking UI states.
6. Page-specific vs site-wide CSS purging
A class that appears unused on the specific page you scanned may be actively used on a different page of the same site — a rule styling a "Related Products" grid, for example, would correctly show as unused when scanning a simple blog post, but is very much in use on product pages. This is why aggressive site-wide CSS purging is risky without testing across a representative sample of page templates (homepage, single post, archive, product page, checkout, etc.), not just one URL. Treat single-page unused-CSS results as a signal to investigate, not a final purge list to apply blindly site-wide.
Frequently Asked Questions
Why does WordPress accumulate large amounts of unused CSS?
Themes and page builders (Elementor, Divi, Gutenberg blocks, WooCommerce) frequently load monolithic stylesheets containing rules for all possible widgets across your entire site, even on pages that only use a small fraction of them.
How does eliminating unused CSS improve PageSpeed and Core Web Vitals?
Browsers must download, parse, and construct the CSSOM (CSS Object Model) for every single rule before rendering content. Purging unused CSS reduces transfer size and main-thread parsing time, directly improving First Contentful Paint (FCP) and Total Blocking Time (TBT).
What is the risk of accidentally purging dynamic CSS classes?
Classes toggled dynamically via JavaScript (e.g. .is-active, .modal-open, .dropdown-show) might not appear in the static initial HTML. When purging stylesheets, always configure safelists/whitelists for dynamic UI states.
Does this tool enforce SSRF security checks?
Yes. All live URL scans strictly reject private network addresses, localhost, loopback, and cloud metadata IPs.
Does the live URL scan analyze my external stylesheet files (style.css, theme.min.css)?
No — this is an important limitation to understand. The live URL scanner only reads CSS found inside inline <style> blocks in the fetched HTML document. It does not follow <link rel="stylesheet" href="..."> references to download and parse externally hosted stylesheet files, which is how the vast majority of WordPress themes, page builders, and plugins actually deliver their CSS. If a scanned page has no inline <style> content (the common case), the tool cannot analyze that page's real CSS and will clearly flag this with a warning. To audit a real external stylesheet, use the "Paste HTML & CSS" tab and paste both the page markup and the full stylesheet text directly.
How accurate is the "used" vs "unused" classification?
The classifier is intentionally simple and conservative: for a class selector it checks whether that exact class name string appears anywhere in the provided HTML; for an ID selector it checks the ID string; for a bare tag selector it checks for an opening or closing tag. This correctly catches straightforward cases but has known blind spots — it cannot detect classes that JavaScript adds dynamically after the page loads (e.g. .is-active, .modal-open), classes used only on other pages of the same site, or complex combinator selectors (like .parent > .child:hover) where only a substring is checked rather than full CSS selector matching logic.