Sass Converter

Converting between CSS preprocessor syntaxes translates stylesheet source among four formats, SCSS, Less, Sass (indented syntax), and Stylus, rewriting variables, mixins, extends, interpolation syntax, and brace or indentation conventions to match the target format. A sample SCSS snippet is preloaded as a starting point, and a swap control reverses the source and target formats in one step, useful for round-tripping a conversion back to its original format to verify nothing was lost.

A variable is declared as $var in SCSS and in Sass, where it carries no semicolon, as @var in Less, and as a plain var = assignment in Stylus; converting between formats rewrites both the declaration and every reference to it throughout the source: an SCSS declaration such as $primary-color: #336699; becomes @primary-color: #336699; in Less, the same $primary-color: #336699 with the semicolon dropped in Sass, and primary-color = #336699 in Stylus. A mixin is declared with @mixin name and called with @include name in SCSS and Sass; Less uses a dotted class-style definition, .name(), called the same way; Stylus omits the @mixin keyword entirely and calls a mixin by name with no prefix, so an SCSS call such as @include button-style; becomes the bare button-style() call in Less and button-style in Stylus.

An extend is written @extend .class in SCSS and Sass, &:extend(.class) in Less, and either @extend .class or @extends .class in Stylus. Interpolation, embedding a variable inside a selector or value, is written #{$var} in SCSS and Sass, @{var} in Less, and {var} in Stylus: a selector written .icon-#{$name} in SCSS becomes .icon-@{name} in Less and .icon-{name} in Stylus, with the rest of the selector left untouched.

SCSS and Less nest rules with curly braces and terminate declarations with semicolons. Sass (indented) relies on whitespace indentation instead, with no braces or semicolons at all. Stylus can optionally omit braces, colons, and semicolons, following whichever convention a project prefers. Single-line (//) and multi-line (/* */) comments carry across every format when comment preservation is enabled; indentation width for the output (2 spaces, 4 spaces, or a tab) is configurable independently of that.

Switching between CSS preprocessor syntaxes is common when migrating codebases, integrating third-party libraries, or adopting a new build tool that favors a different preprocessor. The following scenarios illustrate where format conversion saves significant manual effort.

• Codebase Migration: Move a legacy Less project to SCSS when adopting a framework that ships SCSS partials, without rewriting variables and mixins by hand file by file.
• Library Integration: Import a Stylus-based component library into an SCSS project. Convert the Stylus source so variable names and mixin calls match the conventions already established in the consuming codebase.
• Build Tool Transition: Switch from a Grunt and Less pipeline to a Vite and SCSS pipeline. Batch-convert Less partials to SCSS so the new bundler compiles them without additional loader configuration.
• Syntax Exploration: Evaluate the indented Sass syntax against the more verbose SCSS syntax side by side, comparing line counts and readability before committing to a team-wide style guide.
• Documentation and Tutorials: Provide code samples in multiple preprocessor syntaxes for a CSS tutorial or framework documentation site. Write the example once in one format and convert it to the other three for inclusion in tabbed code blocks.
• Legacy Maintenance: Support an older Sass (indented) codebase that new team members find unfamiliar. Convert snippets to SCSS for review, make edits, then convert back to the indented syntax before committing.
• Design System Portability: Distribute a design-token file across teams that use different preprocessors. Maintain one canonical SCSS token file and generate Less, Sass, and Stylus variants on demand.