# Dart Sass: the reference Sass compiler, and how to install it

> Dart Sass is the reference implementation of Sass written in Dart. This covers what it does, how to install it from npm or Homebrew, and where its compiler model stops being the right choice.

**sass/dart-sass** — The reference implementation of Sass, written in Dart.

- Repository: https://github.com/sass/dart-sass
- Website: https://sass-lang.com/dart-sass
- Stars: 4,225 · Forks: 381
- Language: Dart
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/sass-dart-sass

## What Dart Sass is, and who ends up installing it

Sass is a stylesheet language that compiles to CSS. Dart Sass is the implementation of that language written in Dart, and the repository describes it as the reference implementation. That word matters: when Sass gains a feature, the language definition and the Dart implementation move together, and other implementations follow.

The people who install it are not usually choosing a Sass dialect. They are choosing a compiler binary or a library to drop into a build. That includes front-end developers running a CLI, Node projects importing the sass package, Dart projects depending on the sass package from Pub, and anyone who wants the compiler present without a JavaScript runtime at all, which is what the standalone archive provides: the README says it contains the Dart VM and a snapshot of the executable.

The repository is not archived. The most recent push to the default branch was on 2026-09-22, and the newest release listed is 1.105.0, dated the same day. Releases 1.104.1 and 1.104.0 landed on 2026-09-12 and 2026-09-03. That cadence is worth noting because a Sass version bump can change compilation output, and the changelog is where those changes are recorded.

## One compiler, several entry points: the Dart Sass architecture

The same compiler core is shipped through different wrappers, and picking the wrong wrapper is the most common source of confusion.

The Dart source lives in lib/ and bin/. The bin/ directory is what becomes the sass executable. The package/ and pkg/ directories hold the packaging that produces the npm and Pub artifacts, and the repository uses a buf.gen.yaml and buf.work.yaml pair alongside analysis/ and doc/, which points to a protobuf-based interface layer rather than a single monolithic binary. That is the plumbing behind Embedded Dart Sass, the protocol that lets a host language drive a Dart Sass process instead of reimplementing the compiler.

On the npm side, the README shows a single package exposing both a modern and a legacy surface. The modern one is compile() and compileAsync(), plus compileString() and compileStringAsync() for source passed as a string. The legacy API exists for older integrations. The README is explicit that compileAsync() is substantially slower than compile(), which is a real design consequence: the synchronous path avoids the overhead of the async machinery, and you pay for it when you need asynchronous importers.

In the browser, the picture narrows. The npm package can run directly in a browser, but the README states that since the browser has no filesystem access, compile() and compileAsync() are not available there. To load other files you pass a custom importer to compileString() or compileStringAsync(). The legacy API is not supported in the browser at all.

## Installing Dart Sass and compiling a first file

The README lists six installation routes: Chocolatey or Scoop on Windows, Homebrew on macOS or Linux, the standalone archive, npm, Pub, and building from source. Docker is also covered. Which one you want depends on whether the compiler should live on your machine or inside a project.

On Windows, the package managers give you a sass executable directly.

```cmd
choco install sass
```

```cmd
scoop install sass
```

On macOS or Linux with Homebrew, the formula is namespaced under the sass tap.

```sh
brew install sass/sass/sass
```

For a project rather than a machine, the npm route is the one most build pipelines take. Installing globally gives you the CLI; installing as a dev dependency gives you the CLI and the library.

```bash
npm install --save-dev sass
```

Once it is installed, the library exposes the modern API. The README gives this example, with a note that compileAsync() is substantially slower than compile():

```js
const sass = require('sass');

const result = sass.compile(scssFilename);

// OR

// Note that `compileAsync()` is substantially slower than `compile()`.
const result = await sass.compileAsync(scssFilename);
```

If you would rather not touch the filesystem, compileString() takes Sass source directly. The README uses it in every browser example, and the same call works in Node. What you should see is a result object holding the compiled CSS, which the browser examples print with console.log.

```js
import * as sass from 'sass';

console.log(sass.compileString(`
  .box {
    width: 10px + 15px;
  }
`));
```

For Dart projects, the sass package comes from Pub, and a separate sass_api package is documented for embedding. If you want the compiler with no JavaScript runtime involved, the standalone archive from the GitHub release page is the option: extract it, add the directory to your PATH, restart the terminal.

## Where Dart Sass is the wrong tool

The browser case is the clearest boundary, and the README draws it itself. If your workflow needs to read Sass partials from disk at runtime, the browser build cannot help you. compile() and compileAsync() do not exist there, and the legacy API is unsupported. You can pass a custom importer to compileString(), but that means you are supplying the file resolution logic yourself, which is a different job from running a compiler.

The second boundary is bundler compatibility. The README says the npm package works with all major web bundlers as long as you disable renaming, naming --keep-names in esbuild as the example. A build setup that minifies or renames identifiers without that flag is a setup where the browser build can break.

The third is version drift. The project maintains a compatibility policy covering browser compatibility, Node.js compatibility, and invalid CSS, which is a signal that these boundaries are treated as contractual rather than incidental. If you are pinned to an old Node runtime, that policy is the document to read before upgrading, not the release notes.

Finally, there is a category of user for whom any Sass compiler is the wrong tool: projects with no build step and no intention of adding one. Dart Sass compiles Sass to CSS. It does not remove the need to serve the resulting CSS.

## Dart Sass versus the implementations it replaced

The comparison that matters is not against a competitor product but against the earlier implementations of the same language, and the repository keeps that history in a file called differences.md.

Ruby Sass was the original. The README has a section on behavioral differences from Ruby Sass, which tells you the two do not compile identical input to identical output in every case. If you are porting a stylesheet that was written against Ruby Sass, that file is the one to read first, because the differences are documented rather than accidental.

LibSass was the C++ implementation, and dart sass vs libsass is a question people still search for. The structural difference is that Dart Sass is the reference implementation and LibSass is not. That distinction decides where new language features appear first and which implementation sets the expected behavior when they disagree.

Node Sass was the Node binding to LibSass. The difference in approach is architectural: Node Sass wrapped a native C++ addon, while Dart Sass ships as Dart compiled to JavaScript for the npm package, or as a standalone binary containing the Dart VM. That is why Dart Sass can be dropped into a browser through an import map and Node Sass could not.

For a Rust or JVM build, the search data shows interest in a dart sass maven plugin, but the repository itself does not document one. The mechanism the project does provide for other languages is Embedded Dart Sass, a protocol for driving the compiler from a host process. If your language has an embedded host implementation, that is the supported path.

## Maintenance, upgrades and what the MIT licence covers

The repository is not archived, and the last push was on 2026-09-22. Releases arrive frequently: three versions in the twenty days before that push. Frequent releases are good for language features and bad for anyone who upgrades without reading the changelog, since a compiler change can alter emitted CSS. CHANGELOG.md sits at the top level of the repository, and it is the artifact to diff against when a build produces different output after a version bump.

The upgrade cost depends on which entry point you use. A CLI install through Homebrew, Chocolatey or Scoop is upgraded by the package manager. A project dev dependency is upgraded by changing the version in package.json. A standalone archive is upgraded by downloading a new archive and replacing the directory on your PATH, which is the one route with no automatic mechanism.

Dart Sass is MIT licensed. That is a permissive licence, and the practical implication is that you can ship the compiled CSS and the compiler itself inside commercial products without a copyleft obligation on your own source. This is not legal advice; the LICENSE file in the repository is the authoritative text.

One packaging detail worth knowing before you file a bug: the package.json at the repository root is not the published package manifest. Its own comment says it exists to install dependencies used for testing the Node API and to give GitHub a package name for dependency graph tracking. Its devDependencies include @parcel/watcher, chokidar, immutable and intercept-stdout. If you are debugging a dependency resolution problem, you are looking at the wrong file.

## Conclusion

Adopt Dart Sass if you compile SCSS in a Node, Dart or plain CLI workflow and want the implementation the Sass project itself points to. Do not adopt it if you need to compile Sass in a browser while reading files from disk: the README states that compile() and compileAsync() are unavailable there, and the legacy API is not supported either. Before committing, verify which entry point your toolchain uses, because the npm package exposes both the modern compile()/compileAsync() functions and a legacy JavaScript API, and the README notes that compileAsync() is substantially slower than compile().

## FAQ

### How do I install Dart Sass?

The README lists several routes: choco install sass or scoop install sass on Windows, brew install sass/sass/sass on macOS or Linux, npm install -g sass for a global CLI, npm install --save-dev sass for a project, the sass package from Pub for Dart, a standalone archive from the GitHub release page, or building from source. Docker is also covered.

### What is Dart Sass?

It is the reference implementation of Sass, written in Dart. The repository describes it that way, and the same compiler is distributed through package managers, npm, Pub, a standalone archive and Docker.

### How do I use Dart Sass from JavaScript?

The README shows requiring the sass package and calling sass.compile(scssFilename) with a filename, or sass.compileAsync() for the asynchronous path, which the README notes is substantially slower than compile(). Both are documented on the Sass website's JS API pages.

### Are Sass and SCSS the same?

The repository documents Sass as a language that compiles to CSS and documents Dart Sass as its reference implementation; it does not treat Sass and SCSS as two separate languages in the README, and the compiler accepts SCSS input such as the .box example shown with compileString().

### How does Dart Sass differ from LibSass and Ruby Sass?

Dart Sass is the reference implementation, so features and expected behavior are defined by it first. The repository contains a differences.md file and a README section on behavioral differences from Ruby Sass, which indicates the implementations do not always produce identical output for the same input.

## Sources

- [License: MIT](https://github.com/sass/dart-sass/blob/main/LICENSE)
- [Project website](https://sass-lang.com/dart-sass)
- [README](https://github.com/sass/dart-sass/blob/main/README.md)
- [Releases](https://github.com/sass/dart-sass/releases)
- [sass/dart-sass on GitHub](https://github.com/sass/dart-sass)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sass-dart-sass