SCSS Formatter

An SCSS formatter rewrites SCSS/Sass code with consistent indentation, spacing, and brace layout so it’s easier to read and review. This tool is designed for quick cleanup of messy SCSS — especially code pasted from chats, minified snippets, or quick prototypes.

It formats:

• nested selectors
• declarations and semicolons
• brace indentation
• optional brace-on-new-line style

It assumes your input is valid SCSS/Sass — it formats structure, but it won’t fix broken syntax.

1. Paste your SCSS: Add a selector, component stylesheet, or snippet.
2. Choose formatting options: Indent size (2/4 spaces) and whether opening braces should be on a new line.
3. Copy the formatted output: Paste into your codebase or editor.

• Readable nesting: Clean indentation makes nested selectors easy to follow.
• Cleaner diffs: Consistent formatting reduces noisy PRs.
• Faster debugging: You can spot missing braces and declarations quickly.

Use case 1: Refactor nested components

When a component’s SCSS grows, formatting helps you see nesting depth and keep structure under control.

Use case 2: Clean up pasted snippets

Slack/Discord code snippets often lose formatting. A quick format pass restores indentation and brace structure.

Use case 3: Enforce a consistent style

If your team prefers 2-space or 4-space indentation (or braces on new lines), formatting makes the style consistent.

This formatter gives you two practical knobs:

Indent size (2 vs 4 spaces)

• 2 spaces: compact, common in many web codebases.
• 4 spaces: more breathing room and easier to scan when nesting is deep.

If you’re unsure, pick the style your repo already uses (or the style your linter/formatter enforces).

Opening brace on new line

This is a style preference:

• Off (default): .btn { on the same line
• On: .btn then { on the next line

Both are valid — the important part is consistency.

This is a quick “cleanup” formatter. It focuses on:

• brace indentation
• nested blocks
• semicolon-based line breaks

It assumes your input SCSS is already valid. It won’t fix syntax errors, and it doesn’t aim to match every formatting rule from tools like Prettier.

Practical limitations to be aware of:

• Complex strings that contain braces can confuse simple formatters.
• SCSS has many features (maps, interpolation, advanced mixins). Always review output before committing.
• Comments and edge cases may not format perfectly — treat this as a starting point, not a canonical formatter for production code.

If you’re formatting SCSS that will live in a repo:

1. Use this tool for quick cleanup of pasted/minified snippets.
2. Paste into your editor.
3. Run your project’s official formatter/linter (Prettier, stylelint, etc.) as the final pass.

That way you get the speed of a browser tool and the consistency of your repo’s “source of truth.”

Sass can be written in two syntaxes:

• SCSS: uses braces and semicolons (.btn { color: red; })
• Indented Sass: uses indentation instead of braces (.btn\n color: red)

This tool is designed for brace-based SCSS. If you paste indented Sass, the output may not format correctly because the structure markers are different. In that case, convert the syntax first (or format in an editor that understands indented Sass).

Basic example (2-space indentation)

Input: .parent{color:red;.child{color:blue;}}
Output:

.parent {
  color:red;
  .child {
    color:blue;
  }
}

Advanced example (4-space indentation + brace on new line)

Settings: Indent size = 4, Opening brace on new line = on
Input: $color:red;.btn{color:$color;&:hover{color:darken($color,10%);}}
Output:

$color:red;
.btn
{
    color:$color;
    &:hover
    {
        color:darken($color,10%);
    }
}

It doesn’t fix invalid SCSS

If your code has mismatched braces, missing semicolons, or broken syntax, the formatter can’t “guess” the fix. Correct syntax errors first, then format.

Comments and edge cases

This formatter focuses on core structure. Some complex patterns (like certain comment styles or unusual strings) may not format perfectly. Always review output before committing.

Output isn’t identical to Prettier

If your repo uses a specific formatter (like Prettier + stylelint), run that as the final source of truth. This tool is best for quick cleanup and copy/paste workflows.

If the formatted output looks off:

1. Confirm your SCSS is valid. A missing brace or semicolon can throw off formatting in any tool.
2. Reduce the input to the smallest failing snippet. Formatting issues are easier to spot when you isolate one block.
3. Be careful with strings and comments. If you have strings that include { or }, or unusual comment patterns, review the output closely.
4. Use your repo formatter as the final pass. Browser tools are great for speed, but project tooling should decide the canonical style.

If you repeatedly see edge cases, consider formatting directly in your editor with your usual formatter configuration.

• Use 2 spaces for compact stylesheets, 4 spaces for maximum readability.
• If you’re formatting plain CSS (no variables/mixins), use the CSS Formatter.
• After formatting, consider reducing file size with a minifier if needed (outside this tool’s scope).
• If you’re trying to untangle deep nesting, format first, then refactor: reduce nesting depth and extract shared rules into mixins or utility classes.
• Keep an eye on readability — formatting helps, but SCSS is easiest to maintain when nesting stays shallow.
• If you’re formatting a large snippet, keep the original nearby so you can quickly compare behavior and ensure nothing important changed.

• Format plain CSS with the CSS Formatter.
• Format HTML that uses your styles with the HTML Formatter.
• Clean and format JSON configs with the JSON Formatter.

Formatting runs locally in your browser. Nothing you paste is uploaded or stored. No account is required.