CSS Tools
SCSS ⇄ Sass Syntax Converter
The two Sass syntaxes, in either direction — braces and semicolons added or removed, everything else left exactly as written.
In short
Convert indented Sass to SCSS or SCSS back to indented Sass with one toggle — braces and semicolons added or removed, nesting and & references untouched.
By NaveenKumar T · Updated
Learn: Sass vs SCSS vs LESS vs Stylus: Choosing a CSS Preprocessor
- Both directions, one toggle
- Nesting & references preserved
- Media queries preserved
Runs entirely in your browser — nothing you paste or open here is uploaded, logged, or stored.How we handle data →
Example
SCSS ⇄ Sass Converter: input and output
A toggle switch in indented syntax: two variables, a .slider child, an &:has() state and a reduced-motion query — converted to SCSS.
$switch-h: 24px
$switch-on: #16a34a
.switch
width: 44px
height: $switch-h
.slider
position: absolute
inset: 0
border-radius: $switch-h
background: #cbd5e1
&:has(input:checked)
background: $switch-on
@media (prefers-reduced-motion: reduce)
transition: none$switch-h: 24px;
$switch-on: #16a34a;
.switch {
width: 44px;
height: $switch-h;
.slider {
position: absolute;
inset: 0;
border-radius: $switch-h;
background: #cbd5e1;
&:has(input:checked) {
background: $switch-on;
}
}
@media (prefers-reduced-motion: reduce) {
transition: none;
}
}
Only punctuation changes: every block gains braces, every declaration a semicolon, and the &:has(input:checked) and @media lines nest exactly as before. Switch the direction to SCSS → Sass and the same input comes back out of an SCSS file as this indented form.
Learn more
Two syntaxes, one language
Sass has had two syntaxes since SCSS was introduced in 2010, and the difference is punctuation, not capability. The indented syntax — files ending .sass — has no braces and no semicolons: a block is whatever is indented under its header, and each declaration is a line. SCSS keeps CSS's braces and semicolons, which makes every CSS file a valid SCSS file and is why it became the default.
Variables, nesting, mixins, functions, @use and @forward, control directives, maps, @extend and the built-in modules are identical in both. The same dart-sass binary compiles either one, and it will happily compile a project where some files are .scss and others .sass. So converting is reversible and risk-free in a way that a cross-dialect conversion never is: nothing can be lost in translation, because there is nothing in one syntax that the other cannot express.
What the conversion touches
Sass → SCSS: every block gains braces, every declaration a terminating semicolon, and the result is formatted with prettier's SCSS parser — falling back to the raw braced output if a line will not parse. SCSS → Sass: braces and semicolons are removed, blocks become two-space indented, and one-line rules necessarily expand to several lines because there is no brace to hold them together.
In both directions the rule tree is re-emitted, so indentation is normalised to two spaces regardless of what the input used (tabs included), blank lines are not preserved, and comments are dropped. Everything structural survives: nesting depth, selector grouping, & references in all their forms, @media and @supports headers, @include/@mixin lines, and multi-line values such as maps.
The known gap is the indented syntax's shorthand operators. =name defines a mixin and +name includes one; neither is legal SCSS, and the converter emits them as written rather than guessing at a rewrite. Both syntaxes accept the long @mixin/@include spellings, so converting those lines first — a search and replace — makes the whole file round-trip cleanly.
Why teams convert, in both directions
The mainstream direction is modernisation. Aging Sass codebases hit the same three pressures — formatters and linters that only handle SCSS, editors whose highlighting assumes it, and an ecosystem that publishes every example in it — and converting file by file keeps git blame useful while each file ships independently. Nothing about the build changes, because the compiler was never the problem.
The reverse direction is smaller but real. Teams that deliberately kept the indented syntax, for its density and its brace-free diffs, still have to absorb SCSS constantly: every library's theme file, every documentation snippet, every Stack Overflow answer. Converting those into the house dialect on the way in keeps the codebase consistent without anyone re-keying punctuation. When you need to leave Sass altogether, SCSS / Sass to CSS compiles either syntax with dart-sass, and the CSS preprocessor converter reaches LESS and Stylus.
Help
Frequently asked questions
Everything you need to know about the SCSS ⇄ Sass Converter.
01How do I convert between the two Sass syntaxes?
Pick the direction in the rail — Sass → SCSS to add braces and semicolons, SCSS → Sass to remove them — paste the stylesheet, and press Convert. The file is parsed into a rule tree and re-emitted in the other syntax, so the result is a re-print rather than a text substitution. Download it with the matching .scss or .sass extension.
02Which direction should I pick, and does it matter for my build?
It does not matter to the compiler: dart-sass reads both syntaxes and they support identical features, so the choice is house style and nothing else. Convert to SCSS when you want the ecosystem — prettier, stylelint, most editors and virtually all published documentation assume it — and convert to indented Sass when your codebase already uses it and an incoming snippet does not. Because both compile to the same CSS, each converted file can ship independently with no visual risk.
03Are the indented shorthands =name and +name rewritten as @mixin and @include?
No, and this is the one place the conversion is not complete. =rounded($r) and +rounded(8px) are emitted verbatim inside the braces, which SCSS will not compile. The fix is small: both syntaxes accept the long @mixin and @include forms, so switch those lines before converting, or repair the handful of lines afterwards. Going the other way is safe — @mixin and @include lines are legal in indented syntax and pass through untouched.
04Does anything change apart from braces and semicolons?
Formatting is normalised, because the tree is re-emitted rather than the lines being edited: one declaration per line, two-space indentation whatever the input used, and no blank lines. Comments do not survive — /* */ and // are both stripped before parsing. Everything semantic is preserved: nesting depth, & references such as &__title and &.is-active, selector lists like a, span kept on one line, @media headers, and multi-line values such as Sass maps, which are copied as written.
05Is the SCSS output formatted the way prettier would print it?
Yes, when it can be. Sass → SCSS output is run through prettier's SCSS parser, so it matches what a repo with prettier in CI expects. If a line prettier cannot parse survives the conversion — an =mixin shorthand, say — formatting is skipped and the raw braced emission is returned instead, so you still get a usable file rather than an error. Running it through the [SCSS formatter](/scss-formatter) afterwards is the way to re-apply a specific indent width.
Keep working