Sass variable versus CSS custom property

WHAT THIS TESTS This probes the most common CSS variable confusion: whether you understand that one is a build-time construct and the other is a live, cascading runtime value. The when-to-use judgment reveals practical maturity.

A GOOD ANSWER COVERS A Sass variable, written with a dollar sign, exists only during compilation. The compiler substitutes its value wherever it appears, and the variable itself never appears in the output CSS. It cannot change based on the cascade, media queries, or JavaScript, and it cannot be inspected at runtime. A CSS custom property, written with two dashes and read via var(), is a real CSS feature that lives in the browser. It cascades, inherits down the DOM, can be overridden under different selectors or media queries, and can be read and written from JavaScript at runtime. Choose Sass variables for static configuration consumed at build time, such as values fed into loops, maps, or conditionals to generate CSS. Choose custom properties when the value must change at runtime, like theming, dark mode, or per-component overrides.

COMMON WRONG ANSWERS Saying they are interchangeable. Trying to theme dark mode with Sass variables, which cannot switch after compilation. Expecting a Sass variable to be visible in devtools computed styles. Forgetting that custom properties inherit and cascade.

LIKELY FOLLOW-UPS Can you put a Sass variable inside a custom property declaration? Why can custom properties power dark mode but Sass variables cannot? How do they coexist in one project? What about performance differences?

ONE CONCRETE EXAMPLE You use a Sass map of breakpoints in a loop to generate responsive utility classes at build time, since that logic never changes at runtime. For colors, you define CSS custom properties on :root and override them under a dark-theme selector, so the page reskins live. You might even assign a Sass value into a custom property declaration, getting build-time convenience and runtime flexibility together.