Autoprefixer Online: try a Browserslist query against your CSS in the browser

The demo runs the real Autoprefixer in the browser

Autoprefixer Online is an interactive web demo for Autoprefixer, the PostCSS plugin that adds vendor prefixes and removes the unnecessary ones. The workflow it offers is three steps: paste CSS, choose a Browserslist query, and see the prefixed output immediately in the browser.

The important implementation detail is that there is no backend. The project notes describe it as a small Vite app powered by Autoprefixer and PostCSS, with browser-side CSS processing, so the demo works without a server doing the work. The dependencies confirm it: `autoprefixer` at ^10.5.0, `postcss` at ^8.5.15, alongside `modern-normalize` for the base stylesheet and `prismjs` for syntax highlighting of the output.

What you get for that paste is not a preview of a mock-up but the actual plugin running on your input, which is the whole point. The question it answers precisely is the one that is annoying to answer offline: given this query, what does this plugin actually emit, including which prefixes it decides to strip.

The Browserslist input comes with a link to browsersl.ist to inspect the browsers a query resolves to, which is the step people usually skip and then wonder why the output looked unexpected. The `store` dependency handles persistence, so a query or a pasted snippet can survive a reload rather than being retyped.

The relationship to the real projects is stated directly: Autoprefixer and PostCSS are listed as related projects alongside Browserslist, and the demo sits in the autoprefixer GitHub organisation, so it tracks the plugin it demonstrates rather than being an unaffiliated copy.

Five locales are separate HTML files, not a runtime switch

The localization story is worth understanding because it explains a lot of the repository structure.

There is no runtime language switcher. Each locale is its own static HTML file at the top level: `index.html` for English, `ru/` for Russian, `fr/` for French, `pt-br/` for Brazilian Portuguese and `zh-cn/` for Simplified Chinese. The project notes say that Vite builds every localized HTML file through `vite.config.js`, which is what makes the five pages appear from one source tree.

The consequence for contributors is stated in the contributing section: when you change user-facing text, you update the matching localized HTML files where possible. That is a manual translation chore, and it is the kind of thing that quietly rots in a project like this. A changed button label lives in five files, and nobody's tooling checks that all five were updated.

The CSS and JavaScript are shared, in `src/` for JavaScript, SCSS and app configuration, with `public/` holding static assets copied by Vite. The project notes also point out where the demo content lives: the default demo CSS and the browser target are defined in `src/config.js`.

So the split is a shared application with five hand-translated shells around it. It is a pragmatic choice for a static site with no server to host a translation service, and a common one, but it means the demo's five language versions are maintained by hand and will drift.

Building it is four npm scripts and a destructive docs step

The getting started section is short. Install the dependencies, run the development server, build the static site, and preview the built output:

npm install

npm run dev

npm run build

npm run preview

The package.json fills in what those do. `dev` runs `vite`, `build` runs the shell command rm -rf on the docs directory followed by vite build, `preview` runs `http-server ./docs`, and `start` is an alias for `npm run build`.

Two things to know before you run them. The build script deletes the contents of `docs/` before rebuilding, which the project notes call out explicitly because the generated assets then change after a build, and `docs/` is where the published site lives. If you have uncommitted work in that directory it will be removed. The `start` script being an alias for `build` rather than `dev` is also mildly surprising: `npm start` does not start a dev server, it produces a production build.

The toolchain itself is modest. Vite at ^2.9.13, sass at ^1.53.0, http-server for the preview and npm-run-all as a runner. There is a `.babelrc` and a `pnpm-lock.yaml`, so the lockfile is pnpm's even though the documented commands use npm.

One behaviour is set at the application level: the site enables Autoprefixer's grid option for the demo output. That means what you see is prefixed output with grid handling turned on, which is a deliberate choice and not the plugin's default.

What a demo is good for and what it cannot tell you

The value of this tool is concentrated in one place: it removes the setup cost of answering a question about prefixing.

To do the same thing offline you would install Autoprefixer and PostCSS, write a config file with a Browserslist query, and run a build or a one-off CLI invocation. For a quick question about one declaration, that is a lot of ceremony. Paste the CSS, type the query, read the output.

The second use is explanatory. The demo makes the Browserslist query a first class input rather than something buried in a config file, and the browsersl.ist link lets you check what the query resolves to before trusting the output. For a team where people are confused about why a prefix appears or disappears, that is a genuinely useful teaching tool.

What it cannot do is stand in for a real build. There is no watch mode that processes your actual stylesheets, no way to point it at your project, and no integration with any plugin in your toolchain. The output you inspect is the output for the snippet you pasted, under the demo's own configuration, which includes the grid option.

There is also a version question. The site pins Autoprefixer ^10.5.0 and PostCSS ^8.5.15. If your project runs a different major version of either, the demo may not reproduce your build exactly. That is the reason to treat the demo as an explanatory aid and to check the actual output of your own pipeline before believing it.

The alternative to a browser demo is running the plugin in your own repository through your own PostCSS configuration. The difference in approach is that the demo fixes the configuration for you and shows you the result, while your own setup lets you vary the configuration and applies it to real files.

A demo for a plugin that is now largely a no-op in modern browsers

There is a contextual point that affects how much any of this matters. Autoprefixer is a tool whose value has shrunk as browser support has converged, and a demo of it is even further downstream than the tool.

That is not a criticism of the demo, which does its job of showing prefix behaviour accurately. It is a note about where the remaining value sits. When you ask Autoprefixer to add prefixes for a modern Browserslist query, the honest answer is often that very few prefixes are needed, and sometimes that the ones you have are unnecessary. The tool's most common current use is removing prefixes rather than adding them, which is a cleanup task rather than a feature.

For that reason the browsersl.ist link and the Browserslist query field are more valuable in this demo than the CSS output itself. Understanding why a prefix is or is not emitted means understanding what the query resolves to, and that is the part most people get wrong.

The repository is not archived and the last push was on 2026-06-13, so the demo is being kept working. There are no GitHub releases, and the package version in package.json is 1.0.0, which for a demo reflects that the versioning is not the point.

The licence field in package.json is MIT, while the repository licence is recorded as unknown, and there is no LICENSE file in the top level listing. For a repository that only contains HTML, CSS and JavaScript that the maintainer wrote, that is probably an oversight rather than a restriction, but if you want to reuse the layout or the localization structure, ask first.

Editorial conclusion

Use Autoprefixer Online when you need a quick answer to what a specific Browserslist query does to a snippet of CSS, or when you want to show a colleague the prefixed output without installing a toolchain. Do not treat it as your build step, since the documented workflow is a manual paste and preview rather than a pipeline, and check that the grid option mentioned in the development notes is what you want, because the demo output enables it. Verify first that your local Browserslist and Autoprefixer versions match the ones the site runs, because a demo on a newer build can differ from your own.

Frequently asked questions

Official sources

1. autoprefixer/autoprefixer.github.io on GitHub
2. Issues
3. Project website
4. README