Why it matters
Custom properties make a design system easy to change, but the chain of var() references grows quietly. A colour defined in terms of another, a spacing token that refers to one that was renamed, two themes that each point at the other: none of these throw an error. The browser just treats the property as invalid and the declaration falls back to its initial value, so a button loses its background with no warning.
This tool reads your CSS and builds the graph behind it. Each custom property is a node and each var() is an edge, laid out from base tokens at the top to the properties that consume them. Cycles are found with the same rule the CSS spec uses (every property in the cycle is invalid at computed-value time). References to properties that are never defined are flagged, with a note when a fallback value saves them. Properties that are defined but never read are listed as dead weight. Overrides inside theme selectors, attribute selectors and media queries are shown per context, and the resolved :root values download as JSON tokens.
How to use it
- Paste your CSS: tokens plus the rules that use them.
- Read the summary for cycles, undefined and unused properties.
- Follow the graph to see what depends on a token before you change it.
- Check the overrides table for each theme, and download the resolved tokens.
FAQ
What happens when CSS variables form a cycle?
Every property in the cycle becomes invalid at computed-value time, so any declaration that uses one behaves as if it were unset. Browsers don't log an error, which is why cycles are easy to miss.
Does it understand fallbacks like var(--a, red)?
Yes. If --a is never defined the fallback is used, and the tool shows that the fallback is doing the work.
Can it see variables set from JavaScript or inline styles?
No. It reads the CSS you paste. Properties set by script or in style attributes will show as undefined, so treat those as a prompt to check.
Is my CSS uploaded?
No. It's parsed in your browser and nothing is sent anywhere.
