SCSS Minifier & Beautifier
Format or compress SCSS source — nesting, variables and interpolation all understood. This formats your Sass; it does not compile it to CSS.
Only whitespace and comments are ever changed. No SCSS token is renamed, reordered or removed, so the output cannot behave differently from your input. That also means the size reduction is smaller than tools which rewrite your code — no variable mangling, no dead-code removal — no merged selectors, no collapsed shorthands — and because SQL needs whitespace between tokens, it can only be collapsed, never removed. This formats your source; it does not compile it. Your types are preserved, not stripped.
/*! banner comment is always kept, the usual
convention for a licence header.
Drop a SCSS file here
Up to 4 MB · nothing uploaded
{{ error }}
{{ commentWarning }}
Verified — every token preserved
The output was re-tokenized and compared against the input: all {{ tokenCount }} code tokens are identical, in the same order. Only whitespace and comments differ.
Output rejected
The result did not survive the token check, so it was discarded rather than shown to you. This is a bug in the tool, not in your code — please treat the input as unformatted.
Your SCSS is tokenized and reformatted entirely in your browser. Nothing you paste or drop is ever uploaded to a server.
Formatting Sass source, not compiling it
This reindents or collapses SCSS while leaving every selector, $variable, mixin and
value exactly as written. It is not a Sass compiler: resolving variables, expanding
@mixin/@include, and inlining @import are semantic
operations, and this tool changes only whitespace and comments. Useful when you have inherited
an unreadable stylesheet, not when you want CSS out the other end.
Interpolation is the part that breaks naive formatters
#{$name} contains braces, and a formatter that treats those as block delimiters
will decide it has entered a nested rule and indent the rest of your file inside a block that
does not exist. Interpolation is read as a single unit here, so .#{$k}-box and
calc(100% - #{$gap}) both survive intact.
What SCSS adds over plain CSS, lexically
Only two things genuinely change how the source is read: // line comments, which
are not legal in plain CSS, and interpolation. Everything else preprocessor-specific —
$vars, the & parent selector, nesting, mixin calls — already reads
correctly as ordinary tokens, which is why supporting Sass here cost almost nothing on top of
the CSS engine.
Compiled CSS instead?
Use the CSS Minifier & Beautifier for the output of your build.
Frequently asked questions
Does this compile SCSS to CSS?
No, and that is a deliberate boundary. This formats SCSS source: it reindents or collapses it while leaving every selector, variable, mixin and value exactly as written. Actually compiling Sass means resolving variables, expanding mixins and inlining imports, which is a fundamentally different and much larger tool.
Is nesting handled properly?
Yes. Nested rules indent one level per depth when beautifying, and collapse correctly when minifying. Interpolation such as #{$name} is treated as a single unit rather than being split on its braces, which is what stops a formatter from mistaking it for a nesting level and indenting the rest of the file inside a block that does not exist.
What happens to // comments?
They are recognised as comments, which plain CSS does not do. Minifying removes them along with /* */ comments; beautifying keeps them on their own line. A /*! banner comment is always kept.
Will it break my calc() or my maths?
No. The spaces around + and - inside calc() are required by the CSS grammar and are preserved, including when the expression contains interpolation such as calc(100% - #{$gap}).
Is my source uploaded anywhere?
No. Tokenizing and formatting run entirely in your browser. Nothing is sent to a server.