⬅️ other posts
Published
suggest an edit
🌐

Browser Support in 2025

What new features can I safely use?
Is the 'widely available' badge something I can trust? Should I use BrowsersList to support certain browsers?

Can I safely use the new CSS container queries? How do I decide which browser features my team should or should not use? Do I need to use a polyfill or transpilation step?

There are two main ways people determine this in 2025:

I’ll share the landscape, the choices I considered making, and the choices I’m considering using in my own contexts (my person projects, my government work). I’m not suggesting everyone should follow this as a guide — I’m just sharing my own evaluation publicly, so it can inform your own evaluation.

As I researched this, I was constantly oscillating between the two main approaches. I ended up settling on an approach that uses them both!

My context

I currently work for the State of Maryland (note: this article does not represent my employer’s views), and I have previously worked for the US Federal government. I have discussed these ideas with individual colleagues from my team at Maryland Department of Labor, colleagues from the USWDS team, and (former) 18F colleagues. So many people in the US depend on government services, and they have varying device age and internet access. It’s important that government agencies consider what browsers, browser versions, and browser features we support.

I also personally care about accessibility a lot! I want people to be able to access my work regardless of how they are accessing the site — whether it’s on a bumpy bus with a spotty internet connection, on a huge wide-screen modern computer, or via a screen reader or other assistive technology.

It’s a balance. We want to support older browsers, but we ALSO want to be able to leverage newer browser features. Supporting older browsers means that more people can access our services, which is our goal! But leveraging newer browser features is beneficial too — it means we can enhance the experience for people with newer browsers, and can significantly reduce the maintenance cost.

My stance lately is to use BOTH of the heuristics, depending on the criticality of the use-case (defined below).

Browser features I want to use

What browser features am I thinking about using? Here are a few of my favorites! These are ordered by their “newly available” date (the year it became available in all major browsers).

BrowsersList (market share)

To get a sense of market share across browser versions, you could use browsersli.st. This tool gets data from statcounter/GlobalStats (which is the same data source used by caniuse.com). To see the data itself, “export to csv” on any of the graphs on here, like this browser version over time graph. This heuristic is market-share-based, not time-based.

Here’s an example query: “98% coverage in the US”
(Note: there is a bug right now with calculation of totals, as of Aug 2025).

Pros for market share

  • This framing is pretty close to our actual goal! The framing is inclusive of a proportion of the population.
  • Saying “we support 98% of browsers” is easy to talk about as a goal, people understand it as a target.

Cons for market share

  • The big risk here is that market share data isn’t always reliable, and the numbers can shift a lot over time. For example, in March 2025 Firefox 11 wasn’t in the “98% of browsers” query. One month later in April 2025, Firefox 11 was in that 98% again! Does that mean we should support Firefox 11 now? No… it is NOT very likely that a ton of people in the US started using that ancient browser! That spike is likely caused by bots, not people.
  • Market share is also hard for developers to navigate, and therefore harder for teams to reliably support. A developer has to map the 98% heuristic to a (large) set of supported browsers, and then think about which features are supported in which browsers. It’s possible, but it takes some work to navigate.
  • Rounding issues. Statcounter/GlobalStats only rounds to the nearest 0.01%, and browsers that show up around that number might be inflated in usage. There are many browsers with very low usage on this trailing-end, and in sum they likely skew the data.

Baseline “widely available” (time)

A widely available browser feature is one that has been available in all major browsers for at least 2.5 years. You can see this label “widely available” on MDN and caniuse.com. This heuristic is time-based, instead of market-share-based.

Pros for time-based heuristic

  • This heuristic is straightforward to calculate. “Widely available” was deliberately chosen to make it easy to calculate. What date was it available in all major browsers? What is 2.5 years after that?
  • The “widely available” heuristic is easy for developers to use. It is well-documented on MDN and caniuse.com. There are even text editor plugins and linters for this.
  • It’s easy to explain to users, like during support calls or in documentation. I can explain “Please use a browser from the last 2.5 years.” much easier than I can explain “You see, your browser isn’t supported because it’s not in the top 98% of browsers being used.”

Cons for time-based heuristic

  • Unfortunately, this doesn’t meet the 98% rule that many government agencies follow. Estimates vary, but according to Statcounter GlobalStats in August 2025, 6% of browsers in the US (3% of browsers globally) are older than 2.5 years.
  • Maybe this will be closer to the 98% heuristic soon. The number of older browsers seems to be decreasing over time. Many modern browsers are “evergreen,” meaning they automatically update themselves. On these browsers, users (or IT administrators) no longer need to manually update their browser.

Criticality & Progressive Enhancement

We could choose two different sets of browsers we support - a more conservative set of browsers we support for critical use cases, and a less conservative set we target for progressive enhancement use cases.

  • Critical means it’s essential for a user to be able to use, like being able to read content on the page, or submit forms. This is a pretty low bar, but an important distinction!
    • The most critical things have been part of the web forever – text and form fields.
    • As a visual mnemonic, imagine a web page without any CSS loaded. Most web pages technically still work without CSS! The critical path is unblocked, even if the page is ugly without CSS.
  • Progressive enhancement means something will always work in a critical way in supported browsers – but we enhance the user experience when possible.
    • As an example, if we used css grid for page layout.
    • Note: Progressive enhancement is often also used as a term for the presence/absence of JavaScript, but that is a separate topic. Here we are talking about progressive enhancement of browser features.

Example features and their support

Dialog (allowed with polyfill)

  • The <dialog> feature can be used to make modals without JavaScript, and has been widely supported in browsers since 2022.
  • If you don’t have this browser feature, you wouldn’t see anything at all - that’s a critical use-case failure.
  • Many in-use browsers, including Safari on iOS 10.3—15.3 don’t support dialog.
  • We could potentially use a polyfill like dialog-polyfill to support older iOS browsers, and get to use <dialog> today.

JavaScript Import (allowed, supported in 98% of browsers)

  • The javascript module import feature can be used to load in an external javascript file within a javascript script itself (not just via a DOM node). This can be used for things like conditionally loading a polyfill ONLY when a browser needs it.
  • This feature is very nearly supported in the 98% of browsers. If you support iOS on Safari 10.3 or Chrome 56 as a part of your 98% of browsers calculation, then you couldn’t use this feature for a critical use case. (I think this is safe to use in 2025! The usage is so low in this query, I think it’s from bots and/or rounding errors.)

CSS Cascade Layers (allowed, as a progressive enhancement)

  • CSS Cascade Layers help separate out “layers” of css precedence — like I want my custom CSS to override the component-level CSS from my design system. I want the components to override the baseline styles from my design system. And I want these baseline styles to override the CSS reset.
  • This is pretty safe overall, but it could potentially cause critical issues. The edge case I’m thinking about is if some text gets blocked in browsers without cascade layers, due to conflicting css. Low risk overall, but something to keep in mind.

Most CSS is safe

  • Most CSS is an “enhancement”. Since we always have text representation of important information, we have a solid fallback for the critical tier if the css doesn’t render properly.
  • CSS could be critical if something about our css obscures content, like being absolutely positioned over another element.

Browser support, August 2025

Casey’s browser version support list

I came up with my own browser version support list for August 2025, based on analyzing data from a few different sources. I cross-referenced data from browsersli.st (GlobalStats) and from some analytics from work, trying to remove outliers like Firefox 11, while still supporting older browsers. My goal is 98%, but the query is much more complex than that to account for so many things.

  • 2017 - Safari on iOS 11.0
  • 2019 - Chrome 79
  • 2020 - Safari 13.1
  • 2023 - Edge 109
  • 2023 - Firefox 115

My calculations

Here’s my calculation:

  • Using data from before April (before a weird Firefox 11 usage spike, see my bug report)
  • Using the query cover 96% in US, not < 0.02%, last 2 versions, not firefox <= 11, Firefox ESR, not dead
    • Decreasing our coverage from 98% in US to 96% in US to account for the 2% of “other” browsers likely being bots
    • Removing very-low-usage browsers, to remove the outliers caused by rounding effects (anything < 0.02%)
    • Do include last 2 versions, Firefox ESR, not dead (from the defaults query)
    • Removing the outlier Firefox 11
  • Based on this query, what older browsers would we support for critical use cases? These two in particular stand out:
    • Support Chrome 79 (2019)
      • this has 0.08% of the US market share lately; not a rounding mistake
      • Chrome 79 was released in 2019, and likely IS still being used by actual people.
    • Supporting Safari on iOS 11 (2017)
      • this has 0.12% of the US market share lately; not a rounding mistake
      • Safari on iOS 11 (2017), and likely IS still being used by actual people

Doing your own calculations

If you have access to Google Analytics (or equivalent), you could cross-reference your own traffic, using something like browserslist-ga-export. This is likely closer to your actual target audience. For example, if you are working on business-to-business software-as-a-service, maybe you can actually safely assume everyone has up-to-date browsers! Your Google Analytics data (etc) might support that decision.

Casey’s Browser feature support, August 2025

Here is a list of browser features I’ve thought through using on my projects, and which category they each fall under. This list of browser features is NOT exhaustive. There are hundreds of features that aren’t listed here.

Examples below are from a few sources:

  • Some examples for each category, to make the category clearer
  • Some browser features that come up in discussions on our team
  • Some browser features that have some “buzz,” and are being discussed online (blog posts, etc)

Available in all supported browsers (all 98%)

The dates below are the “newly available” date for each feature, which is the date a feature became available in all major browsers.

✅ Completely safe: Available for full use, without any concerns.

Widely available, but not 98% available

✅ Generally safe: Available as an enhancement

We can pretty much always use these! As as our use doesn’t block any critical path. For these, we do have to check in on older browsers, to make sure content isn’t blocked by conflicting styles. For example, content overlapping other content, or not appearing at all.

  • 2022 - css cascade layers
    • Cascade layers enable us to separate out our css “layers” of prioritization. For example, we want our custom code to take precedence over other code, followed by component code, followed by any “CSS reset” code.
  • 2023 - Container queries
    • Container queries are a lot like media queries, but instead of being limited to browser window size, we can base it on the parent element’s size.

🟡 Conditionally safe: Available only with a backup approach (critical case)

If we were to leverage a fallback approach for these features (polyfill, etc), then we could safely use these features, even for critical paths.

Not Widely Available

In my opinion, it’s not worth it to use these features yet, even for progressive enhancement, because they are not available in enough browsers yet.

🟡 Conditionally safe: Newly Available

These “Newly Available” browser features are available in the latest version of all major browsers, but they have been available for under 30 months (not “Widely Available”). These are settled enough that it’s pretty safe to use as long as we cover IF we have a backup approach, like transpilation or polyfills.

🚫 Not worthwhile: Limited Availability

These “Limited Availability” browser features are NOT yet available in all major browsers. These are not ready for use yet, even with transpilation (etc) because their APIs might still change significantly.

Summary

A short version of my stance:

  • I want to use modern browser features, but I don’t want to prevent anyone from being able to access or interact with my work.
  • I am comfortable using the “widely available” heuristic for most things!
  • But I also evaluate every browser feature in terms of how it would “degrade” in older browsers — ones that are within a rough “98% of usage” heuristic.
Liked this?
I also write about:
🧠
psychology
💻
programming
👔
workplace culture
🌎
community building
or Choose Categories
Casey's headshot

Hi, I'm Casey!

I'm all about helping people be happy and effective.

You might know me from my: talks at tech conferences, or book Debugging Your Brain, or blog posts, or co-hosting the Greater Than Code podcast, or blowing bubbles.