Sass vs SCSS

Sass actually supports two different syntaxes for the exact same language: the original indented Sass syntax, and SCSS, which layers Sass features on top of CSS's familiar curly-brace syntax. This lesson explains both and why SCSS became the dominant choice.

What Is the Difference Between Sass and SCSS?

"Sass" is the name of the language and the compiler. Within that language, there are two file formats: the .sass extension uses indentation instead of curly braces and semicolons, while the .scss extension (Sassy CSS) uses the same braces and semicolons as plain CSS.

Both compile to identical CSS and support the exact same features, variables, nesting, mixins, functions. The only difference is how you format the source file.

// SCSS syntax (.scss)
.card {
  padding: 1rem;
  &-title {
    font-weight: 700;
  }
}

SCSS keeps curly braces and semicolons, so any existing CSS file can be renamed to .scss and it still compiles correctly.

Sass (Indented) Syntax Compared

// same rule written in indented Sass syntax (.sass)
.card
  padding: 1rem
  &-title
    font-weight: 700

Indented Sass uses newlines and indentation instead of { } to define nesting.
Indented Sass omits semicolons at the end of declarations.
SCSS is a superset of CSS syntax; indented Sass is not.
Both syntaxes compile through the same Dart Sass engine to identical CSS.

Sass vs SCSS Cheatsheet

Side-by-side syntax differences between the two formats.

Aspect	SCSS (`.scss`)	Indented Sass (`.sass`)
Braces	`{ }` required	Not used, indentation instead
Semicolons	Required after declarations	Omitted
File extension	`.scss`	`.sass`
CSS compatibility	Valid CSS is valid SCSS	Plain CSS is not valid indented Sass
Popularity	Dominant in real-world projects	Rare outside legacy Ruby-on-Rails apps
Conversion tool	`sass-convert`	`sass-convert` (same tool, either direction)

Why SCSS Became the Standard

SCSS won out for one practical reason: it is a strict superset of CSS syntax. Any existing .css file can be renamed to .scss and compiled without changes, which made adoption effortless for teams with existing codebases.

Indented Sass, by contrast, requires rewriting every existing stylesheet into the indentation-based format before it can compile, a much bigger barrier to adoption.

SCSS lets teams migrate incrementally, one file at a time.
SCSS is easier for developers coming from a plain CSS background.
Nearly every framework, tutorial, and tool defaults to SCSS today.

Converting Between Formats

If you ever encounter a legacy .sass file, the Sass CLI ships a conversion tool that translates between the two syntaxes automatically.

sass-convert style.sass style.scss
sass-convert style.scss style.sass

When You Might Still See Indented Sass

Indented Sass syntax is uncommon today but sometimes appears in older Ruby on Rails projects (which historically bundled Sass tightly) or in developer preference for a more Python-like, brace-free style.

Older Rails asset pipelines sometimes generated .sass partials by default.
Some developers simply prefer indentation-based syntax across every language they use.
This course uses SCSS syntax throughout, since it is the format you will encounter in almost every modern codebase.

Common Mistakes

Assuming "Sass" and "SCSS" are two different languages; they are the same language with two different syntaxes.
Mixing semicolons and curly braces into an indented .sass file, which is invalid in that syntax.
Pasting SCSS code directly into a .sass file expecting it to work without conversion.
Choosing indented Sass for a new project without a strong reason, when SCSS has far better tooling support and community familiarity.

Key Takeaways

Sass the language has two syntaxes: .scss (brace-based) and .sass (indentation-based).
SCSS is a superset of CSS, so any valid CSS file is automatically valid SCSS.
Both syntaxes compile to identical CSS through the same Dart Sass compiler.
SCSS is the overwhelmingly dominant choice in modern projects and is used throughout this course.

Pro Tip

Default to SCSS syntax for any new project. It is a superset of CSS, has better editor and tooling support, and is what the vast majority of documentation, Stack Overflow answers, and teammates will expect.