What this compiles: nesting and &, variables with !default and scope, @mixin and @include with arguments and @content, nested properties, @media bubbling and merging, interpolation, arithmetic, @if, @each and @for, and the common color and string functions. What it will not guess at: @extend, and @use, @forward or @import of another file, since there is no other file here. Those stop the compile with a message rather than producing CSS that behaves differently from Sass.
SCSS to CSS Converter
Compile SCSS to CSS without uploading it anywhere.
About the SCSS to CSS Converter
What is an SCSS to CSS converter?
SCSS is Sass written with braces and semicolons, so it looks like CSS but adds nesting, variables, mixins and loops. Browsers understand none of that, which means it has to be compiled down to plain CSS before it can ship. Normally that happens in a build step. Sometimes you just want to see what a snippet turns into, and setting up a toolchain to answer that question is out of proportion to it.
This compiles it here, in the page. Nothing's uploaded, nothing's fetched from another server, and the result appears as you type.
There's a tradeoff worth being straight about. The real Sass compiler is several megabytes, far too much to send to a browser for a paste box, so this is a compiler written for the parts of Sass people actually paste into a converter. It's checked against real Dart Sass on every feature it claims, and where it meets something it can't do faithfully, such as @extend or an @import of a file it has no way to read, it stops and says so. It won't hand you CSS that quietly means something else.
How to Use This Tool
- Paste your SCSS. Or open a file, or hit Sample to see what it handles.
- Read the badge. Compiled means it worked. Otherwise it names the line and what stopped it.
- Pick an output style. Expanded for reading, compressed for shipping.
- Take the CSS. Copy it, download
style.css, or send it on to the formatter or the minifier with the bar underneath.
Common Use Cases
A compiler in a browser tab is for the moments when a build step is more trouble than the question is worth.
- Checking a snippet: you found some SCSS in an answer somewhere and want to see the CSS it produces before trusting it.
- Debugging a selector: deeply nested SCSS produces selectors that are hard to picture, and seeing them flat explains a specificity problem in seconds.
- Pasting into a CMS: a theme editor that only accepts CSS, when your source is SCSS.
- Learning Sass: putting a mixin in one side and reading the expansion out of the other is the fastest way to understand what it does.
- Handing work to a colleague who does not have the project's build set up.
Going the other way? The CSS to SCSS Converter nests a flat stylesheet. The CSS Formatter tidies the output and the CSS Minifier compresses it. Or browse all our free developer tools.
Frequently Asked Questions
Which parts of Sass does this handle?
Nesting and the parent selector, variables with scope and !default, mixins with positional, named and default arguments plus @content, nested property groups, media queries bubbling out of rules and merging when they nest, interpolation in selectors, properties and values, arithmetic, @if with @else if, @each including the two variable form, @for, and the color and string functions people reach for most. Every one of those is tested against the real Dart Sass compiler, and the output has to match.
Why does it refuse @extend?
Because doing it properly means rewriting selectors across the entire stylesheet, including inside media queries and through chains of other extends, and getting that subtly wrong produces CSS that looks fine and applies to the wrong elements. Refusing is the honest answer. In most cases a mixin does the same job with a clearer result, which is what the Sass documentation itself now recommends.
Why can't it follow @use or @import?
Both pull in another file, and a paste box only has the text in front of it. Rather than silently dropping the line, which would compile something incomplete and look successful, it stops and explains. Paste the partials in together, or drop the line if the file it names only held variables you have already pasted.
Is my code sent anywhere?
No. The compiler is a script on this page, so the SCSS never leaves your browser and nothing is loaded from a third party. Open the network tab and you'll see no request at all while you type, which is not true of every converter offering this.
What happened to my slashes?
They were left alone, on purpose. A slash in CSS is usually a separator rather than a division sign, as in grid-area: 1 / 2 / 3 / 4 or font: 12px/1.5, and turning those into a number would quietly break the rule. Division is only worked out when there is a single slash and a variable involved, which is what $gap / 2 looks like. Sass itself is moving the same way and now prefers math.div.
Do my comments survive?
The /* */ kind do, because they are real CSS comments and Sass keeps them too. The // kind do not, because they are a Sass convenience with no equivalent in CSS. That is the same thing a normal build does, so what you see here is what your pipeline would produce.
Should I use this instead of a build step?
Not for a real project. A build step watches your files, handles partials, adds source maps and runs the full compiler with every feature in it. This is for the times you want an answer now, about a piece of code in front of you, without setting any of that up.