How to Analyze Your CSS with Project Wallace

Project Wallace analyzes a stylesheet by taking either a URL or raw CSS as input, then returning a full "x-ray" of that code: every selector, media query, and property is surfaced, counted, and visualized, alongside reports on colors, typography, specificity, custom properties, and cascade layers. You can use it for a one-off audit of a single file or a whole site's stylesheets. The standalone tools (prettifier, minifier, diff viewer, coverage inspector) require no signup, while the core analyzer and specialized reports are the main product surfaces described on the site.

What you can analyze

The tool is built around the idea that CSS problems are systemic — nobody reviews all stylesheets, so inconsistencies compound invisibly. Its analysis targets those system-level issues:

The site frames the payoff in concrete terms: spotting 47 shades of gray in your tokens, 12 competing font stacks, specificity wars, or 2MB of embedded images.

Step-by-step: running an analysis

1. Choose your input. You can paste a URL or your raw CSS. A URL lets the analyzer fetch the live stylesheets; raw CSS is useful when the file isn't publicly reachable or you want to test a single file in isolation.
2. Submit it to the analyzer. From the site's "Analyze your CSS" entry point, the tool processes the stylesheets and returns results "in seconds."
3. Read the core report first. Start with the full CSS analysis to see structure and complexity — the counts of selectors, media queries, and properties tell you how large the surface area is before you dig into specific problems.
4. Check the quality score. The opinionated score compresses specificity distribution, redundancy, and selector complexity into one number. Treat it as a triage signal: a low score tells you where to look, not what the fix is.
5. Audit design tokens. Review the grouped colors, font sizes, shadows, and spacing. This is where drift shows up — duplicate blues in different formats, off-brand grays, opacity hacks.
6. Inspect custom properties. Compare declared vs. used vs. orphaned properties. Orphaned declarations are dead weight you can usually remove.
7. Visualize cascade layers if you use @layer, to confirm the order and nesting match your intent.

Verifying the results

The tool's output is descriptive, so verification means cross-checking against your source:

• Pick a token the audit flags as duplicated and search your codebase for both values — if they render identically, you have a real consolidation candidate.
• For orphaned custom properties, grep for var(--name) to confirm nothing references them before deleting.
• For specificity concerns, test the flagged selectors in your browser's devtools to see which rules actually win.

Common sticking points

• A URL only captures what's served. Stylesheets injected at runtime by JavaScript, or those behind authentication, won't appear. Paste raw CSS instead in those cases.
• A quality score is a heuristic, not a verdict. The site describes it as "opinionated" and based on best practices — a low score on a legacy codebase may be expected and not worth chasing to zero.
• Token counts include formats. The same color written as hex, rgb(), and a named color can appear as separate values, so deduplicate by rendered value, not by string.
• Standalone tools are separate from the analyzer. The prettifier, minifier, diff viewer, and coverage inspector are one-off utilities with no signup and no paywall; don't expect them to feed results into the main analysis.

When this is the right tool

Use Project Wallace when you need an aerial view of an entire codebase's CSS rather than a review of one component — the scenario the site describes as the "blind spot" where small inconsistencies become systemic debt. For a single formatting or minification task, the standalone tools are faster. The site does not publish pricing details for the core analyzer, so check the site directly if cost matters for your decision.