Online Tool Store
· 5 min read
How to Check Browser Support for a CSS Feature
Heshan Fernando
Co-founder & COO
You’ve just written a layout using a CSS property you read about last week, it looks perfect in your browser, and now there’s a small voice asking whether it works in Safari. Or a tester has filed a bug that only reproduces on one browser, and you need to know in the next five minutes whether the feature you used is the cause.
This is a lookup problem, not a research problem. You don’t need an essay on the feature — you need to know which browsers support it, since when, and whether there’s a caveat you should care about.
What browser compatibility actually means
A “feature” in this context is a specific thing: a CSS property, a value of that property, a JavaScript API, an HTML attribute. Support is per-browser and per-version, and it isn’t binary. A browser can support a feature fully, partially, behind a flag, or with a prefix.
Partial support is where most of the confusion lives. A browser might implement gap for flexbox but not for grid, or support a property but ignore one of its keywords. A compatibility note that just says “supported” hides exactly the detail that will bite you.
The other half is knowing what your users actually run. A feature that landed two years ago is safe for most consumer sites and risky for one serving a fleet of locked-down corporate machines.
Why people get stuck here
- “Supported” without a version is useless. Every current browser supports almost everything. The question is always which older versions don’t.
- Prefixes linger. Some features shipped prefixed for years, so a code sample from an old article may work in tests and fail with modern syntax, or vice versa.
- Mobile browsers differ from their desktop namesakes. Especially on iOS, where every browser uses the same underlying engine.
- Nobody knows the baseline. Teams argue about whether to support a browser version without ever checking their own analytics for whether anyone uses it.
- Fallbacks get skipped. Many features degrade gracefully if you write a fallback declaration first — but only if you remember to.
What a good compatibility lookup looks like
It’s fast enough to use mid-edit
If checking support means leaving your editor, waiting for a heavy page, and scrolling a table, you’ll skip it. A lookup that answers in a couple of seconds is a lookup you’ll actually do.
It surfaces the caveats, not just the checkmarks
“Supported since version 84, but not for grid containers” is the useful answer. A green cell alone can send you shipping something broken.
It helps you decide, not just describe
The real output of a compatibility check is a decision: use it, use it with a fallback, or don’t use it yet. Notes that suggest the fallback save you the second search.
| Support Level | What It Means | What To Do |
|---|---|---|
| Widely available | Shipped in all major engines for years | Use it directly |
| Newly available | In all engines, but recently | Use with a simple fallback declaration |
| Partial | Works, with a documented gap | Check whether your use case hits the gap |
| Behind a flag | Not on for real users | Treat as unavailable |
Common mistakes to avoid
- Testing only in your own browser. Your development browser is the one browser you can be certain about, and the least useful one to check.
- Assuming iOS browsers are independent. On iOS they share the same engine, so a bug in one is a bug in all of them.
- Adding vendor prefixes by reflex. Most modern features never needed them, and stale prefixed declarations can actively override the correct one.
- Dropping a feature because one old browser lacks it. If it degrades gracefully — a slightly different corner radius, no fancy scroll behaviour — that’s often fine.
- Skipping the analytics check. Support decisions should be grounded in who visits your site, not in a general-purpose usage chart.
How to do it with Browser Compatibility Notes
Online Tool Store’s Browser Compatibility Notes gives you quick CanIUse-style feature lookups, running entirely in your browser.
- Open the tool and type the feature name — the CSS property, the API, or the attribute you’re about to use.
- Read the support summary across engines, not just the one you develop in.
- Check for a partial-support note before you assume a green result covers your exact use case.
- If support is thin, decide on the spot: fallback declaration, feature query, or a different approach.
- Write the fallback first in your stylesheet and the newer property second, so browsers that understand both take the newer one.
For the rest of the frontend workflow, the CSS Formatter and the CSS Specificity Calculator sit nearby in the tools directory.
Frequently asked questions
Is this a replacement for testing on real browsers?
No. A compatibility lookup tells you whether a feature exists; only testing tells you whether your specific layout behaves. Use the lookup to avoid obvious dead ends, then test the pages that matter on a real device.
How do I know which browser versions my users have?
Your analytics platform reports it. Before making a support decision, look at the actual distribution for your site — the answer is often that the version you were worried about accounts for a fraction of a percent.
What’s the safest way to use a new CSS feature?
Write the older, widely-supported declaration first and the new one immediately after. Browsers that don’t understand the new property ignore it and keep the fallback, and no JavaScript is involved.
Final thought
Compatibility questions are cheap to answer and expensive to guess at. Look it up, decide on a fallback in the same minute, and move on — the check costs less time than the bug report would.