Sass — Syntactically Awesome Style Sheets — is a CSS preprocessor: a scripting language that extends CSS with programming features and compiles down to standard CSS that browsers can interpret. Sass was created by Hampton Catlin and designed by Natalie Weizenbaum, and was first released in 2006. It has since become one of the most widely used CSS preprocessors in web development, with support in virtually every major front-end build tool and framework.
The fundamental problem Sass solves is that vanilla CSS lacks programming constructs that make large stylesheets maintainable. Pure CSS does not support variables (in the traditional preprocessor sense), functions, nesting, loops, or reusable blocks of styles. As websites grow in complexity, CSS files grow with them — and without organizational tools, CSS becomes difficult to maintain, update, and debug. Sass introduces variables, nesting, mixins (reusable style blocks), functions, inheritance, and control directives (@if, @for, @each, @while) that allow developers to write more maintainable, DRY (Don't Repeat Yourself) stylesheets.
It is important to understand that browsers cannot read Sass files directly. Sass code must be compiled — processed and translated — into standard CSS before it is sent to the browser. This compilation step is handled by the Sass compiler (the official Dart Sass compiler is the current reference implementation) and is typically integrated into the project's build process via tools like webpack, Vite, Gulp, or the Sass CLI. The output is standard .css files that any browser can interpret normally.
Sass exists in two syntaxes: SCSS (Sassy CSS) and the original indented Sass syntax. Both compile to CSS and have access to all the same Sass features — the difference is purely in how you write the code.
SCSS is a superset of CSS — any valid CSS is also valid SCSS. SCSS uses the same curly brace and semicolon structure as standard CSS, which makes it immediately readable to anyone who knows CSS and creates a minimal learning curve for adoption. SCSS files use the .scss file extension. The vast majority of modern Sass usage is in SCSS syntax — it is the default syntax referenced in documentation, tutorials, and framework integrations. When developers say 'Sass,' they almost always mean SCSS in practice.
Example SCSS: $primary-color: #3498db; .button { background-color: $primary-color; &:hover { background-color: darken($primary-color, 10%); } }
The original Sass syntax (sometimes called 'indented syntax' or just 'Sass') uses indentation instead of curly braces to define blocks and omits semicolons. It is more concise but less familiar to developers who come from a CSS background. Files use the .sass extension. The indented syntax is the older of the two and is less commonly used in modern projects, though it remains fully supported. Some developers prefer its cleaner visual structure; others find the lack of braces confusing.
Understanding Sass's core features explains why it has been adopted so widely. Each feature solves a specific limitation of plain CSS and contributes to more maintainable stylesheets.
Sass variables store values — colors, font sizes, spacing units, breakpoints — that are referenced throughout the stylesheet. When a value needs to change (for example, a brand color update), it changes in one place and updates everywhere the variable is used. Sass variables are declared with the $ prefix: $brand-color: #e74c3c; $font-size-base: 16px;. Note that CSS custom properties (CSS variables, declared with --) are now also widely supported in browsers and serve a similar purpose — the key difference is that Sass variables exist only at compile time (they disappear in the output CSS), while CSS custom properties exist at runtime and can be changed dynamically with JavaScript.
Sass allows selectors to be nested inside other selectors, mirroring the HTML hierarchy and making the relationship between styles immediately readable. The parent selector is represented by the ampersand (&) when referencing the parent within a nested block. Nesting can be overused — deeply nested structures (more than 3 to 4 levels) produce long, overly specific CSS selectors that can be difficult to override. The general recommendation is to nest only when it meaningfully reflects a structural relationship, not as a default organizational approach.
Mixins are reusable blocks of CSS declarations that can be included in any selector using @include. Mixins can accept arguments, making them parameterized style templates. A common use case is a mixin for vendor-prefixed CSS properties, button variants, or responsive breakpoints. Example: @mixin flex-center { display: flex; justify-content: center; align-items: center; } .container { @include flex-center; }. Mixins with arguments allow dynamic values to be passed: @mixin button($bg, $color) { background: $bg; color: $color; }.
The @extend directive allows one selector to inherit the styles of another, avoiding code duplication for selectors that share a common set of styles. Placeholder selectors (defined with %) are style blocks that are not output unless extended — they exist purely as reusable style templates. Extends should be used carefully: they produce grouped CSS selectors in the output, which can lead to unexpected selector combinations in large stylesheets. Many Sass style guides recommend preferring mixins over extends for most use cases because mixins produce more predictable output.
Sass files prefixed with an underscore (_variables.scss, _mixins.scss) are partials — they are not compiled to individual CSS files but are imported into other Sass files. The modern Sass module system uses @use and @forward (replacing the deprecated @import) to load partials and control which variables, mixins, and functions are available in each file. @use creates a namespace for the imported file, preventing naming collisions: @use 'variables' as v; .button { color: v.$primary; }. This module system is the current best practice for organizing Sass in large projects.
Sass includes a library of built-in functions for color manipulation (lighten(), darken(), mix(), adjust-color(), rgba()), math operations (round(), ceil(), floor(), percentage()), string manipulation, and list operations. These functions are available in all Sass files and allow dynamic style calculations at compile time. Custom functions can also be defined using @function and @return, enabling reusable computed values.
Using Sass in a modern web project requires integrating the Sass compiler into the project's build pipeline. The specific integration method depends on the project's build tool.
Dart Sass is the primary, actively maintained Sass compiler and the reference implementation. The older LibSass (C++ implementation) is now deprecated and should not be used for new projects — it does not support modern Sass features including the @use/@forward module system. Install Dart Sass via npm: npm install --save-dev sass. The Sass CLI can compile .scss files directly: sass input.scss output.css --watch. The --watch flag enables automatic recompilation when source files change.
In most modern projects, Sass compilation is integrated into the project's build system rather than run manually. Vite supports Sass via the sass npm package — install sass and Vite automatically handles .scss files. webpack uses sass-loader in conjunction with css-loader. Create React App (via react-scripts) supports Sass by installing the sass package. Next.js supports Sass natively with the sass package installed. In all cases, the project's build tool handles compilation as part of the development and production build pipeline — developers write .scss files and the build tool outputs compiled CSS.
A common Sass file organization pattern is the 7-1 architecture: seven folders (abstracts, base, components, layout, pages, themes, vendors) plus one main.scss file that imports all partials. This pattern is documented at sass-guidelin.es and provides a scalable structure for large projects. Smaller projects may use a simpler structure with partials for variables, mixins, and component styles. Regardless of structure, separating variables and configuration from component styles and from layout styles makes Sass codebases easier to maintain.
Sass is not the only approach to writing more maintainable CSS. Understanding how it compares to alternatives helps developers choose the right tool for their project.
CSS custom properties (CSS variables, e.g., --color-primary: #3498db) now handle the most common use case for Sass variables — defining reusable values — natively in the browser. CSS custom properties can be changed at runtime with JavaScript and respond to media queries, which Sass variables cannot. However, Sass variables are still useful for values that should only exist at compile time (computed layout values, breakpoint thresholds used in @media conditionals), and Sass features like mixins, nesting, and functions have no direct CSS equivalent. Many projects use both: CSS custom properties for runtime-dynamic values and Sass for compile-time organizational features.
CSS Modules is a build-tool-based approach that automatically scopes CSS class names to the component they're defined in, eliminating naming collisions in large projects. CSS Modules can be used with or without Sass — many projects combine CSS Modules with SCSS. CSS Modules is particularly common in React and Vue projects where component-scoped styles are a priority.
Tailwind CSS is a utility-first CSS framework that provides pre-defined utility classes applied directly to HTML elements. Tailwind and Sass represent fundamentally different approaches to styling: Sass is a CSS authoring tool (you write CSS, just with more features), while Tailwind replaces most custom CSS with utility classes in markup. Many projects use one or the other based on team preference, project type, and design system requirements. Tailwind has grown significantly in adoption in the 2020s and is now common in React and Next.js projects; Sass remains widely used in component library development, design system tooling, and projects requiring complex, calculated styles.