One entry file, several partials
A single textarea handles a snippet. It falls apart the moment your variables sit in _tokens.scss and your breakpoint mixin sits in _mixins.scss, because pasting the entry file alone gives the compiler names it has never seen. This page keeps a tab per file and hands the whole set to the compiler together, so @import resolves the way it does on your machine.
Two rules decide how the files fit together:
- A name starting with an underscore is a partial. Sass never compiles a partial on its own, so it produces no stylesheet of its own and exists to be imported.
- The entry file is the one compiled. Only its output reaches the right pane. Switch which file holds that role with the button under the tabs, and the underscore rule blocks the obvious mistake of pointing it at a partial.
Imports drop the underscore and the extension. Writing @import 'tokens' in the entry file pulls in _tokens.scss. Order matters, because a variable has to be defined before the rule reading it, which is why token files sit at the top of almost every entry file you will meet.
@import 'tokens';@import 'mixins';.panel {padding: $space-3;border: 1px solid $line;}$line: #d5e3e8;$space-1: 4px;$space-3: $space-1 * 4;.panel {padding: 16px;border: 1px solid #d5e3e8;}Notice what survives the trip. The arithmetic $space-1 * 4 is gone, replaced by 16px. Both partials vanish from the output entirely, since a partial contributes definitions rather than rules. What ships is one flat stylesheet a browser reads without knowing Sass exists.
This compiler is LibSass, so some newer syntax fails
The engine here is a WebAssembly build of LibSass running inside your tab. LibSass was retired in 2020 and stopped at the Sass language as it stood then, which makes the gap against the Dart Sass in your build pipeline worth knowing before you paste production code.
| Syntax | Compiles here | What to do |
|---|---|---|
@import 'partial' | Yes | Works across every open tab. Deprecated in Dart Sass, still the syntax most existing projects use. |
@use and @forward | No | The module system arrived after LibSass froze. Rewrite the pair as @import to test a file here. |
math.div($a, $b) | No | Use the slash form $a / $b, which still divides in this engine. |
map-get, @each, @if | Yes | Maps, loops, and conditionals all run. The theme sample above is built on them. |
@mixin, @content, @extend | Yes | Placeholders group selectors, mixins copy blocks in. The two samples show the difference in output. |
@media with nesting | Yes | Nested queries bubble to the top level, same as they do in Dart Sass. |
| Colour functions | Mostly | mix, lighten, rgba, and friends work. The newer color.adjust module functions do not. |
Nothing leaves your browser. The compiler, the editors, and the download all run in page JavaScript, so a stylesheet from a client project stays on your machine. A few hundred lines across half a dozen partials compile in well under a second, though the WebAssembly binary itself is a couple of megabytes on first load.
The first error is the only error
Sass stops at the first thing it cannot resolve. A run that fails tells you nothing about the rest of the file, which catches people out when a large paste reports one problem and they assume the remainder is clean.
The error panel names the file, the line, and the column. Press Open that line and the tab switches to the file at fault with the cursor already there. Load the missing variable sample to see the shape of it: the entry file reads $card-bg, the partial never defines it, and the compiler reports an undefined variable rather than silently writing an empty value.
Three messages account for most failures:
- Undefined variable. Either a typo, or an
@importsitting below the rule that needs it. Check the order at the top of the entry file first. - File to import not found or unreadable. The name in the import has to match a tab.
@import 'ui/buttons'looks for a folder this page does not have, so flatten the path to_buttons.scsswhile testing. - Invalid CSS after ... Usually a missing semicolon or brace a line or two above the one reported, since the parser only notices once the next token makes no sense.
Picking an output style
Four styles ship the same rules with different whitespace. Expanded is the readable one and the right choice while you are checking what the compiler produced. Compressed strips every space and newline for the file a browser downloads.
| Style | Looks like | Use for |
|---|---|---|
| Expanded | One declaration per line, braces on their own lines | Reading the output and diffing it against a previous build |
| Nested | Indentation mirrors the source nesting depth | Tracing which nested block produced which flat selector |
| Compact | One rule per line | Scanning a long stylesheet for a specific selector |
| Compressed | A single line, no whitespace | The production file, though your bundler normally does this step |
The size counter tracks the raw byte count, not the transfer size. Servers gzip CSS, and gzip closes most of the gap between expanded and compressed, so the difference on the wire is far smaller than the counter suggests.
This page checks Sass, it does not replace your build. There is no source map, no folder structure, no watch mode, and no node_modules, so a @import pointing at Bootstrap or a design system package has nothing to resolve against. For anything shipping to users, run Dart Sass through your bundler and treat the output here as a second opinion.
When a different page suits the job better
Reach for this one when several files have to see each other: a token partial feeding a component file, a mixin library you are testing a call against, a bug you suspect lives in import order. For a single snippet with no imports at all, the SCSS to CSS converter is the lighter page. Writing the indented Sass syntax rather than SCSS braces? That belongs in the Sass compiler, since the two dialects are parsed differently and pasting one into the other reports an error on line one.
