Compiler state
{{ summaryHeadline }}
{{ summaryDetail }}
{{ badge.label }}
Choose the source dialect before compiling.
Pick the CSS format used by the compiler and export files.
Paste a single stylesheet. Imports that need extra files should be inlined before browser compilation.
{{ sourceHint }}
Choose whether the result includes a source-map handoff.
Use 0 to 10 decimal places for calculated values.
Use source comments only for debugging or review builds.
{{ sourceCommentsEnabled ? 'On' : 'Off' }}
Include the current editor source inside source-map exports.
{{ sourceMapContentsEnabled ? 'On' : 'Off' }} 
{{ compiledCss || compileError || 'No compiled CSS yet.' }}
{{ sourceMapJson || 'No source map generated for the current settings.' }}
Metric Value Detail Copy
{{ row.metric }} {{ row.value }} {{ row.detail }}
Check Status Detail Copy
{{ row.check }} {{ row.status }} {{ row.detail }} 
{{ resultJson }}
Tags: Devtools, Text
Export to PDF Fullscreen
Customize
Advanced
:

SCSS and indented Sass let stylesheet authors write variables, nesting, mixins, functions, and reusable structure before the browser receives ordinary CSS. The compiled result is the stylesheet the browser can load, so the conversion step has to preserve selector meaning, declaration order, color math, media rules, and any debugging information the next person may need.

Small Sass snippets often need a fast check outside a full project build. A design token change, a nested selector, or a one-file theme experiment can be easier to inspect when the source and compiled CSS sit next to audit cues. That kind of check is useful for review, but it is not a replacement for the build system that resolves a whole dependency tree.

SCSS source compiled into CSS with source map and audit checks

Modern Sass projects also have version and syntax boundaries. The newer module system uses @use and @forward, while older LibSass-based compilers can lag behind current Dart Sass behavior. Source maps add another choice: they help debugging by linking generated CSS back to Sass source, but they may also carry source text that should not ship with a public release.

How to Use This Tool:

Paste one stylesheet or load one local file, choose the source dialect and CSS format, then review the compiled output with the metrics and audit rows before copying it into a project.

  1. Choose Input syntax. Use SCSS for braces and semicolons, Indented Sass for whitespace-sensitive .sass source, or CSS passthrough when ordinary CSS needs a parser and formatting check.
  2. Set Output style. Expanded CSS is easiest to review, Compressed CSS is the smallest handoff, and Compact CSS or Nested CSS can help compare output from older Sass workflows.
  3. Paste into SCSS source, drop text, or browse for one SCSS, Sass, CSS, or TXT file. Files above about 1.5 MB are rejected, and extra dropped files are ignored so the compile stays single-source.
  4. Open Advanced when you need source maps, decimal precision from 0 to 10 places, source comments for review builds, or source contents inside generated map output.
  5. Read Compiled CSS first. If the panel shows a Sass error instead of CSS, fix the reported syntax or line context before trusting the metrics.
  6. Check Compile Metrics for input size, output size, rule blocks, at-rules, feature counts, compile profile, and runtime. These values help spot a blank compile, an unexpectedly large map handoff, or output that changed more than expected.
  7. Use Compiler Audit as the confidence check. Resolve Parser result failures, review module or import warnings, and treat a fallback compiler warning as a signal to verify the same source in your normal Sass build.

Interpreting Results:

The Compiled CSS panel is the handoff text, but the Compiler Audit determines how much confidence to place in it. A Parser result pass means the current source produced CSS without a blocking compiler error. It does not prove the CSS matches your production build, resolves every partial, or behaves correctly in every browser.

A smaller output is not automatically better. Compressed CSS may be right for release, while expanded CSS is often better for review because selector expansion, nested rules, and generated source comments are easier to inspect.

  • Compiler engine: Review means the main browser Sass compiler was unavailable and the limited fallback handled only simple variable replacement and nesting.
  • Module directives: Review means @use or @forward was detected, so compare the result with a Dart Sass build before using it.
  • Import handoff: Review means @import appeared in the pasted source, and missing partial files may change the real project output.
  • Source Map JSON appears only when a source-map option returns a map. If source contents are included, the map can expose the stylesheet text used for debugging.

Technical Details:

SCSS is a CSS-like Sass syntax, which is why plain CSS normally parses as SCSS. Indented Sass represents the same stylesheet ideas with indentation and line breaks instead of braces and semicolons. Compilation resolves Sass-only constructs such as variables, nesting, parent selectors, mixins, includes, functions, loops, and conditionals into CSS that browsers understand.

The browser compiler used here is LibSass-based when the main compiler loads. That matters because LibSass is deprecated and does not follow every current Sass language feature. Modern module syntax is the most visible boundary: @use and @forward belong to the newer module system, while LibSass-era workflows usually depend on older patterns such as @import.

Source maps are debugging artifacts. They connect generated CSS positions back to original source positions so developer tools can show the Sass line behind a CSS rule. Including source contents in a map is convenient for a one-file handoff, but it can reveal private selectors, design tokens, comments, or paths when the map is distributed with a release build.

Transformation Core:

Stage What happens What to verify
Source dialect SCSS, indented Sass, or plain CSS is parsed according to the selected input syntax. Choose the syntax that matches the pasted file, especially for .sass indentation.
Sass expansion Variables, nested selectors, parent references, mixins, functions, and control rules are resolved when the compiler supports them. Review compile errors and compare module-heavy files with the project build.
CSS formatting The generated stylesheet is emitted as expanded, compressed, compact, or nested CSS. Use readable output for review and compressed output only when the CSS has been tested.
Source map handoff Optional source-map output can be omitted, returned as separate JSON, or embedded into the compiled CSS. Check whether map source contents should be included before sharing or shipping files.
Metrics and audit Line counts, byte sizes, rule counts, Sass feature counts, runtime, compiler status, and warning rows are summarized. Treat warnings as review gates, not as cosmetic notes.

Audit Boundaries:

Audit row Review trigger Corrective check
Compiler engine The main compiler is unavailable and a limited fallback is used. Confirm the same source with a normal Sass compiler before using the CSS.
Parser result The compiler returns a Sass syntax error or no CSS. Fix the reported line, quote, brace, directive, or function issue in the source.
Module directives @use or @forward appears in the source. Use a Dart Sass project build for module-system files.
Import handoff @import appears and external partials may be required. Inline dependencies or compile in the project where partial files are available.
Source map A source map was requested but no map appears, or source contents may be sensitive. Use the external JSON panel for debugging handoffs and omit source contents for public release files.

Privacy Notes:

The pasted source, compiled CSS, source-map JSON, metrics, audit rows, and downloads are handled in the browser session rather than sent to a server for compilation. The page may still need network access to load the compiler library, so avoid pasting sensitive design tokens or proprietary stylesheet comments on machines, browsers, or networks you do not trust.

  • Generated source maps can include the current stylesheet text when Map source contents is on.
  • Embedded source maps can make CSS files larger and can carry debugging data directly inside the CSS text.
  • Local browser processing does not replace code review, license review, or production build validation.

Worked Examples:

Reviewing a theme button. A 9-line SCSS snippet defines $brand: #2563eb;, a .button rule, and a nested &:hover selector. With Input syntax set to SCSS and Output style set to Expanded CSS, Compiled CSS should show the base selector and the expanded hover selector. Compiler Audit should keep Parser result, Module directives, and Import handoff at Pass before the CSS is copied.

Checking a module-system file. A source beginning with @use "tokens"; and later referencing tokens.$text may be normal in a Dart Sass project, but Compiler Audit should mark Module directives as Review. If Compiled CSS shows an error, the source belongs in the project build rather than a single-file LibSass check.

Preparing a source-map handoff. A small nested navigation stylesheet can be compiled with Source map set to External and Map source contents on for a local debugging handoff. Source Map JSON should appear, and Compile Metrics should show the selected map profile. Turn source contents off before sharing the map outside a trusted review context.

FAQ:

Are pasted SCSS files uploaded for compilation?

No server compile step is used. The source is read and compiled in the browser session, although the page may need network access to load the compiler library.

Why does @use or @forward show a review warning?

Those directives belong to the modern Sass module system. The visible compiler engine is LibSass-based when loaded, so module-system files should be checked with a Dart Sass build.

Can this compile a project with partial imports?

Only the pasted or loaded stylesheet is available to the compiler. If Import handoff shows Review, inline the needed partials or compile in the project where those files are present.

What should I do when fallback mode appears?

Treat the output as a rough preview. The fallback handles a conservative subset such as simple variables and nesting, so verify the source with the normal Sass compiler before using the CSS.

Is CSS passthrough a full CSS validator?

No. It is useful for running ordinary CSS through the same parser and output-style controls, but it does not test visual rendering, browser support, imported files, or unused rules.

Glossary:

SCSS
The CSS-like Sass syntax that uses braces, semicolons, and the .scss extension.
Indented Sass
The original Sass syntax that uses indentation and line breaks instead of braces and semicolons.
CSS passthrough
A mode for checking and re-emitting ordinary CSS through the compiler path.
LibSass
A deprecated Sass compiler family that remains useful for older workflows but does not support every current Sass feature.
Module directives
@use and @forward rules that load Sass members through the modern module system.
Source map
A debugging file or embedded data URL that maps generated CSS positions back to Sass source positions.
Source contents
Original stylesheet text included inside source-map output for easier debugging.

References: