sublime-autoprefixer runs Autoprefixer inside Sublime Text, and only where you want it

The plugin is a bridge to the Node Autoprefixer

sublime-autoprefixer is a Sublime Text plugin for prefixing CSS, and the mechanism is worth understanding before you install it. The plugin does not implement prefixing. It uses the Autoprefixer module and the Can I Use database, so the rules come from the same source as the tool everyone else uses. The repository makes that structure visible: `Autoprefixer.py` holds the plugin, `node_bridge.py` is the bridge to Node, and `autoprefixer.js` is the script on the other side, with `node_modules/` checked into the tree and `package.json` pinning the dependencies. The Node side is a small set of packages, Autoprefixer itself at 10.6.1 or later, PostCSS, postcss-safe-parser and postcss-scss, plus get-stdin for reading the buffer. The declared dependencies do not include a CSS preprocessor beyond SCSS, and the documentation says the plugin works with CSS and SCSS but not other preprocessors. So the plugin is a thin editor front end for a Node process that must exist on the machine.

It adds only what is needed, and removes what is not

The value the plugin claims is twofold. First, it only adds the necessary prefixes, so the stylesheet is not bloated with every prefix a browser once needed, and second, it removes existing prefixes that are no longer required. That second half is what makes it more than a one-way converter, and it is the reason the plugin is worth running on a file that already has prefixes in it, rather than only on new code. The targeting is data-driven, because the decisions come from the Can I Use database rather than from a hard coded list in the plugin, and the documentation says you can specify which browsers you want to target. The plugin is described in one line as a way to stop caring about vendor prefixes, and the screenshot in the repository shows the effect on a stylesheet. For a team with a defined browser support policy, the browser list in the settings is where that policy is expressed.

Install through Package Control, with Node.js 20 on the PATH

Installation is through Package Control, and you restart Sublime afterwards. The requirement that catches people out is stated in bold in the documentation: you need Node.js 20 or newer installed, and it must be in your $PATH, which you check by running `node --version` in your command line. On macOS there is an extra wrinkle, because you need to make sure Node is in `/usr/local/bin` or symlink it there. The documentation also links to the Autoprefixer version in use, so you can see which one is bundled. Since the repository ships `node_modules/` and a lockfile, the plugin's own Node side is prepared, but your system still has to provide the Node runtime that the bridge calls into. A common failure mode is therefore a plugin that appears installed and does nothing, because the bridge cannot find the interpreter, which is why the version check is called out in the install section rather than in a troubleshooting page.

The browsers list is the whole configuration

Settings live under Settings, Package Settings, Autoprefixer, and the default configuration sets a browser list and disables prefixing on save:

{
	"browsers": ["defaults"],
	"prefixOnSave": false
}

The `browsers` value is an array of rules, and the documentation links to the supported browser names. A wider example shows how the rules compose, covering the last version of each browser, a global market share threshold, a US specific threshold and two Internet Explorer versions:

{
	"browsers": [
		"last 1 version",
		"> 10%",
		"> 5% in US",
		"ie 8",
		"ie 7"
	]
}

The result is prefixes for the last version of each browser, for all browsers with more than 10 percent global share, for browsers with more than 5 percent share in the US, and for Internet Explorer 7 and 8. The `prefixOnSave` option defaults to false, so by default the plugin only acts when you ask it to. That default is the right one for a plugin that rewrites files, since a save-triggered rewrite that disagrees with your build output is a bad trade.

Run it on a selection, and give it a shortcut

The everyday use is the command palette. In a CSS file you open it with Command, Shift, P and choose `Autoprefix CSS`, and the documentation notes an important variant: you can create one or more selections before running the command to prefix only those parts of the file. That is the feature that makes the plugin usable on a large stylesheet, because rewriting the whole file on every invocation is a different risk from rewriting the block under the cursor. A keyboard shortcut can be set up by opening Settings, Key Bindings, User and adding a binding that calls the `autoprefixer` command:

[
	{
		"keys": [
			"alt+super+p"
		],
		"command": "autoprefixer"
	}
]

The command name in the binding is the same one the menu entry uses, and the repository ships `Autoprefixer.sublime-commands` and `Main.sublime-menu` for those entry points.

Project settings override the user settings

The plugin can be configured per project, which matters when a single Sublime installation serves several codebases with different browser support requirements. You add an `Autoprefixer` object to the `settings` object in the project's `.sublime-project` file, and the project specific settings take precedence over the default and the user settings:

{
	"settings": {
		"Autoprefixer": {
			"browsers": [
				"last 1 version"
			]
		}
	}
}

The repository root also holds `test.css`, `test.scss` and `test.html`, which are the fixtures for checking the behaviour against both syntaxes, and the `Autoprefixer.sublime-settings` file is the packaged defaults. The overall picture is a plugin with one real decision to make, the browsers list, and three places to make it, defaults, user settings and project settings.

No releases, and a September push to the repository

The maintenance picture for this plugin is thin in a specific way. There are no GitHub releases, so the plugin is installed through Package Control rather than from a tagged archive, and the last push to the repository was on 2026-09-26 with the repository not archived. The licence is MIT, with a `license` file at the repository root, and the plugin ships as a Sublime package with the `.no-sublime-package` marker in the tree, which is the convention for keeping the package build out of the source repository. Because `node_modules/` is committed and `package-lock.json` is present, the Node side of the plugin is pinned, and the package.json lists the Autoprefixer version range the plugin was built against, so an update to the underlying module arrives with a change to those pins rather than silently. The practical question for a team is whether the browser list they need is expressible in the rules Autoprefixer supports, since that list is the only configuration the plugin exposes.

Editorial conclusion

Sublime Text users who edit CSS or SCSS by hand and want prefixes added and cleaned up on demand, without a build step, will find this plugin small, configurable and easy to justify, since it targets browsers explicitly and removes prefixes that are no longer needed. It is the wrong tool if your project already has a PostCSS or build pipeline, because then Autoprefixer belongs in that pipeline rather than in the editor, and it is the wrong tool for preprocessors other than SCSS. Before installing it, confirm Node.js 20 or newer is on your PATH, since the plugin cannot run without it, and set the browsers list deliberately rather than leaving the default.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. sindresorhus/sublime-autoprefixer on GitHub