By Hugo Giraudel

What’s the Difference Between Sass and SCSS?

By Hugo Giraudel

I’ve written a lot lately on Sass, but some recent comments made it clear that not everyone knows exactly what Sass refers to. Here’s a bit of clarity:

When we talk about Sass, we usually refer to the preprocessor and the language as a whole. We’ll say, for example, “we are using Sass”, or “here is a Sass mixin”. Meanwhile, Sass (the preprocessor) allows two different syntaxes:

  • Sass, also known as the indented syntax
  • SCSS, a CSS-like syntax


Initially, Sass was part of another preprocessor called Haml, designed and written by Ruby developers. Because of that, Sass stylesheets were using a Ruby-like syntax with no braces, no semi-colons and a strict indentation, like this:

// Variable
!primary-color= hotpink

// Mixin
    -webkit-border-radius= !radius
    -moz-border-radius= !radius
    border-radius= !radius

    color= !primary-color
    width= 100%
    overflow= hidden


As you can see, this is quite a change compared to regular CSS! Even if you’re a Sass (the preprocessor) user, you can see this is pretty different from what we are used to. The variable sign is ! and not $, the assignment sign is = and not :. Pretty weird.

But that’s how Sass looked like until version 3.0 arrived in May 2010, introducing a whole new syntax called SCSS for Sassy CSS. This syntax aimed at closing the gap between Sass and CSS by bringing a CSS-friendly syntax.

// Variable
$primary-color: hotpink;

// Mixin
@mixin border-radius($radius) {
    -webkit-border-radius: $radius;
    -moz-border-radius: $radius;
    border-radius: $radius;

.my-element {
    color: $primary-color;
    width: 100%;
    overflow: hidden;

.my-other-element {
    @include border-radius(5px);

SCSS is definitely closer to CSS than Sass. That being said, Sass maintainers have also worked to make both syntaxes closer to each other by moving ! (variable sign) and = (assignment sign) from the indented syntax to $ and : from SCSS.

Now, when starting a new project, you may wonder which syntax you should use. Let me enlighten the path and explain the pros and cons of each syntax.

Pros for Sass indented syntax

While this syntax might look weird, it has some interesting points. First of all, it is shorter and easier to type. No more braces and semi-colons, you don’t need all that stuff. Even better! No need for @mixin or @include, when a single character is enough: = and +.

Also the Sass syntax enforces clean coding standards by relying on indentation. Because a wrong indent is likely to break the whole .sass stylesheet, it makes sure the code is clean and well formatted at all times. There is one way to write Sass code: the good way.

But beware! Indenting means something in Sass. When indenting a selector, it means it is nested into the previous selector. For instance:

    color: hotpink

        float: left

… will output the following CSS:

.element-a {
    color: hotpink;

.element-a .element-b {
    float: left;

The simple fact of pushing .element-b one level to the right means it is a child of .element-a, changing the resulting CSS. Be very careful with your indentation!

As an aside, I feel like the indentation based syntax will probably suit a Ruby/Python team more than a PHP/Java team (although this is debatable, and I’d love to hear opinions to the contrary).

Pros for SCSS syntax

For starter, it is fully CSS compliant. It means, you can rename a CSS file in .scss and it will just work. Making SCSS fully compatible with CSS has always been a priority for Sass maintainers since SCSS was released, and this is a big deal in my opinion. Moreover, they try to stick as close as possible to what could become a valid CSS syntax in the future (hence @directives).

Because SCSS is compatible with CSS, it means there is little to no learning curve. The syntax is already known: after all, it’s just CSS with a few extras. This is important when working with inexperienced developers: they will be able to quickly start coding without knowing the first thing about Sass.

Moreover, it is easier to read because it actually makes sense. When you read @mixin, you know it is a mixin declaration; when you see @include, you are calling a mixin. It doesn’t make any shortcuts, and everything makes sense when read out loud.

Also, almost all existing tools, plugins and demo for Sass are developed using the SCSS syntax. As time goes, this syntax is becoming pro-eminent and the default (if only) choice, mostly for the above reasons. For instance, it is getting quite hard to find a clean syntax highlighter for Sass indented syntax; usually, there is only SCSS available.

Final thoughts

The choice is up to you, but unless you have really good reasons to code using the indented syntax, I would strongly suggest using SCSS over Sass. Not only is it simpler, but it is also more convenient.

I once tried the indented syntax myself and liked it. I liked how short and easy it was. I was actually about to move an entire code base to Sass at work before changing my mind at the last minute. I thank my past-self for halting that move, because it would have been very difficult to work with several of our tools had we used the indented syntax.

Also, please note Sass is never in uppercase, no matter whether you’re talking about the language or the syntax. Meanwhile, SCSS is always in uppercase. Need a reminder? to the rescue!

  • nicooprat

    Sass needs a better way to handle maps. For now it has to be on the same line, which is unreadable. Here’s an example : Now switch to Sass syntax (gear icon in the upper right corner). Ouch.

    Other than that, I personally still prefer to use the indented syntax.

  • great, thanks for share

  • typecandi

    Thank you!

  • I use Stylus which enables me to leave out ALL punctuators, even the colons. I’m completely screwed, right? :P

    • Юрий

      I tried Stylus and felt uncomfortable when faced necessity to escape MS filter property and something else. May be they resolved the issue by now.
      So I prefer SCSS, especially after they presented BEM syntax support.

  • canariasnorly


  • Rashid Aslam

    Thanks! you made it very clear

  • Marc Beuret

    Thanks Hugo for these concise and clear explanations !

  • I fell so in love with Sass syntax that it wasn’t easy for me to move. Then I started developing a rails app and even ruby on rails convention over configuration now generates .scss for view files.

  • Ronan Connolly

    Thanks for clearing this up, Sassy CSS is awesome! :)

  • Michael Barber


  • good

  • I use mixed scss and sass in one project. Most likely it is a bad practice. For example, for the variables I use _variables.scss, and for writing styles – style.sass. Just once trying sass do not want to go back to the routine of ” { } ; “

  • Himanshu Jain

    Thank you for this super simple explanation! :)

  • Harsha

    How can i call background image in sass lang any one please help on this. Regards,Harsha

  • dellwolf

    Thank you, way clearer now

  • chrisco484

    The days when white space was significant in a source file have largely departed with the strange, virtually extinct, dinosaur languages like Cobol (unfortunately JScript has an annoying throwback mutation to these days in certain places).
    I used sass for a while but abandoned it for scss when simple spacing errors would cause failures. Every other programming language I’ve ever used demands wrapping blocks in curly brackets { } – it’s not a problem folks. Two extra characters is all you need and you’ve made everything explicit instead of leaving things in the hands of the ‘white space’ gods.

  • Thanks a lot for your great article. I want to choose scss because it’s more readable. Thanks

  • McFlyyy

    why does any sass search are nowadays returning css syntaxes ? freaking annoying

Get the latest in Front-end, once a week, for free.