Why it matters
Most of what people first reached for Sass to do is now in CSS itself. Nesting shipped in every major browser in 2023, custom properties have been everywhere for years, and calc(), color-mix() and relative colour syntax cover most of the maths and colour functions. Dropping the Sass build step means one less dependency and styles the browser can read directly, but going through a stylesheet by hand is slow.
This converter does the mechanical part. It parses the SCSS, turns top-level $variables into custom properties, and writes out mixins and @extend the way Sass would. BEM-style selectors like &__title can't be nested natively, so those are written out in full. Variables used in selectors or media queries are inlined, because var() doesn't work there. Anything that only Sass can do (loops, conditions, maps, functions, modules) is listed with its line number and left for you, so the output never silently changes meaning.
How to use it
- Paste your SCSS (one file, with any partials pasted in).
- Choose nested or flattened output, and custom properties or inlined values.
- Read the notes: anything not converted is listed with its line.
- Copy or download the CSS and test it against the Sass output.
FAQ
Can native CSS replace Sass completely?
For nesting, variables and simple maths, yes. Loops, conditionals, maps and custom functions still need Sass or a build step, and the converter lists every one it finds.
Why are some selectors written out instead of nested?
Sass can join a suffix to the parent, as in &__title becoming .card__title. Native CSS nesting can't, so those rules are written out in full.
Why are some variables inlined even with custom properties on?
var() only works in property values. Variables used in selectors or media queries are replaced with their value.
Is my code uploaded?
No. It's converted in your browser.
