Sass Syntax

What You’ll Learn

Sass supports two syntaxes. This page compares SCSS and the indented syntax, shows how the same styles compile either way, and walks through five beginner examples.

What Is Sass Syntax?

Official docs: Sass ships two ways to write the same language. Your team picks one (or mixes them). The compiler still outputs plain CSS either way.

• SCSS — file extension .scss; braces and semicolons like CSS.
• Indented syntax — file extension .sass; indentation replaces braces/semicolons.
• Feature set is the same: variables, nesting, mixins, modules, and more.
• Each syntax can load the other (for example with @use).

📄 The SCSS Syntax

SCSS is a superset of CSS (with a few small exceptions). Essentially all valid CSS is valid SCSS. That similarity makes it the easiest syntax to learn and the most popular.

@mixin button-base() {
  display: inline-flex;
  position: relative;
  border: none;
  vertical-align: middle;

  &:hover {
    cursor: pointer;
  }

  &:disabled {
    cursor: default;
    pointer-events: none;
  }
}

📄 The Indented Syntax (.sass)

This was Sass’s original syntax, so it uses the .sass extension and is sometimes just called “Sass.” It supports the same features as SCSS, but:

• Wherever CSS/SCSS would use curly braces, indent one level deeper.
• Wherever a statement can end at the end of a line, that counts as a semicolon.
• A few extra indented-only rules appear throughout the official reference.

@mixin button-base()
  display: inline-flex
  position: relative
  border: none
  vertical-align: middle

  &:hover
    cursor: pointer

  &:disabled
    cursor: default
    pointer-events: none

⚖️ SCSS vs Indented Syntax

📈 Multiline Statements (Indented)

Official docs (Dart Sass 1.84.0+): in the indented syntax, a statement may span multiple lines when the break happens where the statement cannot end—inside parentheses or brackets, or between keywords in a Sass-specific @-rule.

LibSass and Ruby Sass do not support this. Many projects still run older Dart Sass (for example 1.69.x), where that multiline style will fail to compile. Prefer keeping indented statements on fewer lines, or use SCSS for long values, until your toolchain is on 1.84+.

Examples Gallery

Side-by-side where it helps. Open View Compiled CSS—both syntaxes produce the same CSS for equivalent source.

$brand: #036;

.button {
  background: $brand;
  color: #fff;

  &:hover {
    background: #024;
  }
}

$brand: #036

.button
  background: $brand
  color: #fff

  &:hover
    background: #024

.button {
  background: #036;
  color: #fff;
}
.button:hover {
  background: #024;
}

@mixin card($radius) {
  border-radius: $radius;
  padding: 1rem;
}

.panel {
  @include card(8px);
  border: 1px solid #ddd;
}

@mixin card($radius)
  border-radius: $radius
  padding: 1rem

.panel
  @include card(8px)
  border: 1px solid #ddd

.panel {
  border-radius: 8px;
  padding: 1rem;
  border: 1px solid #ddd;
}

$theme: dark;

.card-#{$theme} {
  display: grid;
  grid-template-columns: 1fr 2fr;
}

.card-dark {
  display: grid;
  grid-template-columns: 1fr 2fr;
}

$bp: 768px;

@media (min-width: $bp) {
  .sidebar {
    width: 240px;
  }
}

$bp: 768px

@media (min-width: $bp)
  .sidebar
    width: 240px

@media (min-width: 768px) {
  .sidebar {
    width: 240px;
  }
}

$space: 1rem;

.box {
  margin: $space;
  // SCSS keeps braces and semicolons
  padding: $space * 2;
}

.box {
  margin: 1rem;
  padding: 2rem;
}

🚀 Real-World Use Cases

• New projects — default to SCSS for hiring and tooling familiarity.
• Migrating CSS — rename .css → .scss and adopt Sass gradually.
• Legacy indented codebases — keep .sass or convert file by file.
• Mixed repos — @use a .sass partial from SCSS (or the reverse).
• Teaching — show both once, then standardize on one team style.

⚠️ Common Pitfalls

• Wrong extension — SCSS in a .sass file (or the reverse) fails to parse.
• Mixing braces into .sass — indented files do not use { } / ; the SCSS way.
• Thinking features differ — syntax is style; capabilities match.
• Multiline indented on old Dart Sass — needs 1.84+; older versions error.
• Inconsistent team style — pick one primary syntax for new files.

💡 Best Practices