b2KIT

Sass / SCSS Playground

Write SCSS or Sass and compile to CSS in real time with variable, mixin, and nesting support.

Tested tool guide Tested browser tools Checked August 16, 2026

What Sass / SCSS Playground does, with a checked example

An in-browser editor with a source pane on one side and compiled CSS on the other: every keystroke re-parses your SCSS (or indented Sass) and rewrites the output. Variables, mixins, nesting, and the & parent selector all expand in place, so you see exactly what a build tool would ship. The surprise for most first-timers is that the result is dead, static CSS: no variables survive in the output to tweak later, and nothing is rendered, so you get stylesheet text, not a styled preview. Modern Sass also rejects the old @import habit in favor of @use.

Worked example

A concrete input and expected output from the current implementation.

Input

$gap: 8px;
$radius: 12px;

@mixin chip {
  display: inline-flex;
  border-radius: $radius;
}

.chip {
  @include chip;
  gap: $gap;

  &.active {
    font-weight: 600;
  }
}

Expected output

.chip {
  display: inline-flex;
  border-radius: 12px;
  gap: 8px;
}
.chip.active {
  font-weight: 600;
}

Variables resolve to their literal values, the mixin expands inline at the @include position, and & concatenates with the enclosing selector to form .chip.active with no space. The tokens $gap and $radius appear nowhere in the output because the compile step consumes them.

How the result is produced

1

Compilation pipeline

The source is tokenized and parsed against the Sass grammar: declarations, nested rule blocks, variable references, mixin definitions and include statements. Nesting is flattened into descendant selectors, & is replaced by the parent selector, mixins expand in place at the @include position, and variables are substituted. The result is then serialized back out as ordinary CSS in source order.

2

Two syntaxes, one grammar pair

SCSS keeps CSS's braces and semicolons. The indented syntax, the original Sass, drops both and treats indentation and line breaks as structure. The grammars are not interchangeable: a brace inside indented-mode input is a parse error, and equivalent source compiles to identical CSS in either mode, so the choice is about which your project already uses.

Good uses

  • Prototyping a small token set: define $colors and $spacing as variables, build a component or two with mixins, and read the compiled CSS before committing to a real build pipeline.
  • Refactor verification: extract a repeated block into a mixin or reorganize imports, then confirm the compiled CSS is exactly what it was before the change.
  • Learning or vetting snippets: watch how nesting, &, and interpolation expand step by step, and check whether a Sass snippet found online compiles the way its author claims.

Limits and checks

  • The output is one-shot CSS: variables and mixins disappear into concrete values, so the result cannot be re-themed later by changing one token. What you see is the final shipped stylesheet.
  • The tool compiles; it does not render. No HTML is attached, so nothing here tells you whether the styles look right on a page, only whether they are valid, fully expanded CSS.
  • Deprecated-but-working is not modern: darken(), lighten(), and @import still compile (with warnings), and a snippet that leans on them is reproducing tech debt the current Sass documentation says to avoid.

Common questions

Can I preview how the styles actually look?

No. The output pane is CSS text, and nothing in the tool attaches it to a document. To see the styles rendered, paste the compiled CSS into a scratch HTML file or the browser DevTools and inspect an element. Use the playground to verify the generated stylesheet, then render it elsewhere.

What is the difference between typing SCSS and Sass here?

SCSS is CSS with extra features: braces and semicolons included. The indented syntax is the original form: no braces, no semicolons, with indentation and line breaks carrying the structure. Feed brace-based code into indented mode and parsing fails. Pick the mode that matches your project; equivalent source compiles to the same CSS either way.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools