CSS to SCSS Converter

Convert flat CSS into nested SCSS syntax — groups related selectors under a single parent using & nesting.

Drop a .css file or click to browse

CSS input

Lines: 34Selectors: 7

SCSS output

.card {
  background: #fff;
  border-radius: 8px;
  padding: 16px;

  &:hover {
    box-shadow: 0 4px 12px rgba(0, 0, 0, 0.15);
  }

  .title {
    font-size: 18px;
    font-weight: 600;

    a {
      color: #111;
      text-decoration: none;

      &:hover {
        color: #2563eb;
      }
    }
  }
  .subtitle {
    color: #666;
  }
}

@media (max-width: 768px) {

  .card {
    padding: 8px;
  }

}

Lines: 35

How CSS to SCSS nesting works

The converter parses your CSS into individual rules, then groups selectors that share the same leading compound selector (the part before any combinator or pseudo-class) under one parent block. A selector like .card:hover becomes &:hover nested inside .card, and a descendant selector like .card .title nests .title one level deep — multi-level descendants (.card .title a) recurse to the correct depth automatically. Combinators (>, +, ~) are preserved with & (e.g. & > span). At-rules like @media keep their own nested scope, and comments are preserved in place.

This mirrors how you'd hand-nest a stylesheet when migrating to Sass — it does not invent variables or mixins, it only restructures selector nesting so the SCSS compiles to equivalent CSS. To go the other direction, or work with plain CSS, see CSS Formatter or CSS Minifier. To pull class names out of markup first, try the CSS Class Extractor.

Built and maintained by Meet Shah · Last updated 19 July 2026

What this tool is used for

Nesting a flat stylesheet by shared selector prefixes.
Producing a starting SCSS structure from existing CSS.
Grouping related rules together for readability.
Migrating a stylesheet during a toolchain change.
Seeing which selectors share a prefix worth nesting.

Frequently Asked Questions

How does it decide what to nest?: It groups rules by the leading compound selector, so `.card`, `.card:hover` and `.card .title` all fold under one `.card` block. Nesting recurses, so `.card .title a` lands at the right depth rather than stopping at two levels.
When is & used?: For anything attached to the base rather than descended from it — `.card:hover` becomes `&:hover`, `.card.active` becomes `&.active`. A descendant becomes a plain nested selector, and a combinator keeps its operator, so `.card > span` nests as `> span`.
Are media queries preserved?: Yes, as their own block with its contents nested inside. Sass allows a media query to be nested inside a rule too, which often reads better — that transformation is a judgement call this converter leaves to you.
Do comments survive?: Yes. They are parsed as nodes in their own right rather than stripped, so their position relative to the rules around them is kept. That matters when comments are section markers in a large stylesheet.
Why parse instead of using regular expressions?: Because declarations must be split on semicolons that are not inside parentheses or strings. A plain split breaks `rgba(0, 0, 0, .5)` apart at nothing and cuts a `content: "a;b"` string in half.
Is deep nesting a good idea?: No — nesting mirrors the source's structure, and past three levels the generated selectors get long, specific and hard to override. Treat the output as a starting point and flatten the parts that nested only because the original happened to be ordered that way.

Common errors and gotchas

Nesting so deeply that the generated selectors become extremely specific and hard to override.
Assuming nesting changes the output, when it is purely an authoring convenience.
Losing the original rule order, which decides which of two equal-specificity rules wins.
Nesting media queries in a way that duplicates them throughout the output.
Treating nesting as an improvement in itself, when flat CSS is often clearer.