CSS Vendor Prefixer

Vendor prefixes let browsers ship a feature before its specification was settled. A property under -webkit- or -moz- was explicitly experimental, so the vendor could change its behaviour without breaking pages that used the standard name. The idea did not survive contact with reality: developers shipped prefixed properties to production, prefixed syntax became a de facto standard that browsers could not remove, and some engines ended up implementing other vendors' prefixes to render the web correctly. Modern browsers now put experimental features behind flags instead, which is why the list of prefixes worth adding keeps shrinking.

Every prefixed declaration is a duplicate line in a render-blocking file. Prefixing a handful of properties that genuinely need it costs almost nothing; prefixing every transform, transition, and flex property in a large stylesheet for browsers nobody uses adds real weight and makes the file harder to read. Add prefixes deliberately, based on the browsers you actually support, and prune them when your support target moves — treating them as permanent is how stylesheets accumulate dead code.

Far less than you used to, and for most projects the honest answer is no. Properties that needed prefixes for years — transform, transition, animation, border-radius, box-shadow, flexbox — have been unprefixed in every current browser for a long time. A handful still benefit, notably -webkit-backdrop-filter for Safari, -webkit-appearance for form controls, and some -webkit- text and scrollbar properties. Prefixing everything indiscriminately just makes your stylesheet bigger.

Because when a browser understands both, the last one it can parse wins. Putting the standard, unprefixed property last means a modern browser uses the standard behaviour, while an older engine that does not recognise the standard property falls back to the prefixed line above it. Writing them the other way round means old browsers work and new ones are stuck on legacy behaviour — which is the opposite of what you want, and a genuinely common mistake.

If you have a build pipeline, use Autoprefixer with a browserslist config. It consults the Can I Use database and adds exactly the prefixes your declared browser support requires, which means the prefixes shrink automatically as your support target moves forward. This tool is for the situations where a build step is not available — a CMS theme field, an email template, a snippet for a third-party platform, or checking quickly which prefixed form a property takes.

Decide what you support first, then check. Your analytics will tell you which browsers real visitors use, and Can I Use will tell you what each of those needs for a given property. That order matters: teams routinely carry prefixes for browsers that stopped appearing in their traffic years ago, which costs bytes on every request and makes stylesheets harder to read for no benefit at all.

No. Every one of these tools runs entirely in your browser using JavaScript. Your stylesheet is never uploaded, never logged, and never sent to any server — you can confirm this by opening your browser devtools Network tab while you work, or by disconnecting from the internet after the page loads and watching everything continue to function. That makes it safe to paste proprietary or client CSS.