SCSS Formatter

SCSS files drift out of shape faster than plain CSS because there is so much more shape to lose. Nesting depth communicates structure, so a block indented at the wrong level actively misleads you about which selector it belongs to. A Sass map written across one long line is unreadable; the same map with one entry per line is a lookup table. And @each loops, @if branches and mixin definitions all carry braces that need to line up before you can trust what you are reading.

This page runs Prettier 3.9.6 with its SCSS parser configuration, in your browser. Prettier discards your existing line breaks and reprints the file from its parse tree, which is what makes the output consistent across a whole team. It is a formatter only: it does not compile SCSS to CSS, does not resolve @use or @import, and does not evaluate a single variable or function call.

SCSS constructs the formatter understands

The SCSS parser covers the full modern Sass language, not just CSS with nesting:

• The module system. @use, @forward, namespace prefixes such as t.$brand, with configuration blocks, and the built-in modules sass:map, sass:math, sass:color and friends.
• Nesting and the parent selector. Ordinary nesting, &__element and &--modifier BEM suffixes, and the inverted form .parent & { … } that reaches outward.
• Mixins and functions. @mixin, @include with a trailing content block, @content, @function with @return, default parameter values, and argument lists that wrap when long.
• Control directives. @if / @else if / @else chains, @each over lists and maps with destructured $key, $value pairs, @for loops and @while.
• Placeholders and extension. %placeholder selectors and @extend.
• Interpolation. #{$name} inside selectors, property names, values, media queries and strings.
• Flags and directives. !default, !global, @error, @warn and @debug.

Sass maps get the treatment that matters most: a map with several entries is printed one entry per line with the closing parenthesis on its own line, so it reads like the data structure it is instead of a wall of commas.

Comments behave differently from plain CSS

SCSS supports two comment styles and they mean different things. A /* … */ block comment is a CSS comment and survives compilation into the output stylesheet. A // … line comment is a Sass comment and is stripped by the compiler before any CSS is produced.

Both are preserved here, exactly as written, because a formatter that deleted your comments would be worse than no formatter. What Prettier will change is their surrounding whitespace: a comment on its own line stays on its own line, a trailing comment stays trailing, and runs of blank lines around them collapse to at most one.

One thing to watch: since // comments never reach the compiled CSS, they are the right place for notes to other developers, while /*! … */ is the right form for a licence banner that must ship. The formatter respects the distinction rather than normalising one into the other.

What formatting cannot tell you

Because nothing is compiled, this page cannot tell you whether your SCSS actually works. A reference to $brand that was never defined, a call to map.get() on a variable that is not a map, an @use pointing at a file that does not exist, or a mixin invoked with the wrong number of arguments will all format perfectly and then fail the moment you run sass. Formatting is a syntax operation; those are semantic errors that need the whole dependency graph.

Genuine syntax errors — an unclosed brace, a mixin definition missing its parameter list, an @if with no condition — are reported with the line and column where the parser gave up.

Nothing is uploaded. The parser runs in a Web Worker on your own machine, which is worth knowing given how often internal design-system source contains unreleased product names in its variable names.