CSS Vendor Prefix Generator
Input your CSS properties below to automatically add vendor prefixes. This tool helps ensure cross-browser compatibility for modern CSS features.
CSS Properties
Enter one CSS property per line or separate with semicolons
WebKit
(Safari, Chrome)
Mozilla
(Firefox)
Microsoft
(IE, Edge)
Opera
• Modern browsers may not need all prefixes, but they ensure compatibility with older versions
• Consider using a build tool like Autoprefixer for production code
• Some properties like 'display: flex' need prefixing for older browsers but not for newer ones
How to use CSS Vendor Prefix Generator
- 1
Paste your CSS
Drop your CSS rules, such as a flex or transition declaration, into the code input box.
- 2
Select the prefixes
Choose which vendor prefixes to add, including -webkit-, -moz-, -ms-, and -o-, based on the browsers you need to support.
- 3
Generate prefixed CSS
Click Generate Prefixes to produce a version of your code with the matching prefixed properties added.
- 4
Copy the result
Copy the prefixed CSS from the output and paste it back into your stylesheet.
CSS Vendor Prefixes Explained
What a vendor prefix actually is
A vendor prefix is a short string a browser maker put in front of a property or value name to ship a feature before it was finalized. The four you will meet are -webkit- for the engine behind Chrome, Safari, and modern Edge, -moz- for Firefox, -ms- for old Internet Explorer and the original Edge, and -o- for the old Presto-based Opera. So during the transition years you might write both transition-property and -webkit-transition-property, the prefixed one for browsers that shipped it early and the bare one for browsers that follow the final standard.
Mechanically a browser ignores any property it does not recognize, which is what makes prefixes safe to stack. You can list the prefixed variants first and the standard property last, and each engine simply takes the line it understands and skips the rest.
Why prefixes existed in the first place
Prefixes were a pragmatic answer to a hard problem. When a new feature like gradients, transforms, or flexbox was still being designed, browser vendors wanted to let developers experiment without locking in syntax that the specification might change. Shipping the feature behind a prefix was a way of saying this is experimental and may move. If the final standard differed, the unprefixed property could adopt the corrected behavior while the prefixed one preserved the old one, so existing pages would not silently break.
In practice the system backfired. Sites came to depend on -webkit- features so heavily that other engines eventually had to implement some -webkit- prefixed properties themselves just to render the web correctly. That outcome is exactly why the whole approach has been largely abandoned in favor of feature flags for experimental work.
How to write prefixed and standard together
The rule is simple and order matters: write every prefixed version you need, then write the standard, unprefixed property last. Because later declarations win when all are understood, putting the standard line at the bottom means a fully modern browser uses the final, correct behavior, while an older one falls back to the prefixed line it understands. This tool follows that convention, emitting the prefixed variants you select alongside the original standard declaration so the cascade resolves the way you expect.
The same idea sometimes applies to values, not just property names, since a few features were prefixed on the value side too. The safe habit is identical: provide the older prefixed form, then let the standard form override it for browsers that have caught up.
Most modern CSS no longer needs prefixes
This is the part worth internalizing: the great majority of properties that once required prefixes do not anymore. Transitions, transforms, animations, box-shadow, border-radius, gradients, and the modern flexbox syntax are all supported unprefixed across current browsers. Adding -webkit-, -moz-, -ms-, and -o- to those today produces dead code that bloats your stylesheet, can confuse future readers, and in rare cases even activates buggy old behavior. If your project only targets current browsers, you very likely need no prefixes at all.
That is why a thoughtful workflow does not prefix everything by reflex. It prefixes only what the actual browser targets require, which keeps the output lean and honest rather than padded with lines no one will ever execute.
Where prefixes still genuinely matter
A handful of features remain prefix-only or prefix-first in shipping browsers, and these are where a prefix is not legacy cruft but a current requirement. The -webkit- prefix in particular still appears for things like the line-clamp technique used to truncate text to a fixed number of lines, certain backdrop and appearance behaviors, and some scrollbar and tap-highlight tweaks on mobile Safari. For these, omitting the prefix means the feature simply does not work, so this is exactly when reaching for a prefix is correct.
If you support older but still-real browser versions for a specific audience, prefixes also re-enter the picture for properties that were standardized only recently. The deciding question is never how the property feels but what your support matrix actually contains.
Autoprefixer and the modern build approach
The current best practice is to stop hand-writing prefixes and let a tool add them from real data. Autoprefixer, run as part of a build step, reads your project's declared browser support list and inserts exactly the prefixes those browsers require, no more and no less, using up-to-date compatibility data. You write clean standard CSS, and the correct prefixes are generated automatically at build time, then dropped again the moment your support list no longer needs them.
This converter is the manual counterpart to that workflow, ideal when you are not running a build pipeline, when you want to add a specific prefix to a snippet quickly, or when you are learning how the prefixed and standard forms relate. For a large codebase, wiring up Autoprefixer means you never think about this again.
Check support before you prefix
Before adding any prefix, confirm whether it is actually needed by checking a current compatibility reference such as caniuse, which shows, property by property, which browser versions support the standard form and which still demand a prefix. Pairing that lookup with an explicit list of the browsers your project supports turns prefixing from guesswork into a decision you can defend. The maintenance cost of stale prefixes is real, so deleting ones you no longer need is as valuable as adding the ones you do.
Frequently asked questions
What are CSS vendor prefixes for?
Which prefixes can this tool add?
Does it prefix every property I paste?
Do I still need vendor prefixes today?
Is my CSS sent anywhere?
Related tools
Keep going with these handy tools