Browser and device compatibility — what you actually need to support

“Support every browser” is not a usable brief — it is unachievable in practice and not actually necessary, because the realistic target is the specific set of browsers and devices your own visitors are actually using, which is a question your own analytics already answers rather than a guess.

Why an unbounded browser compatibility brief is the wrong starting point

Every browser and every device combination behaves slightly differently, and testing against literally every historical combination that has ever existed is neither practical for a small business budget nor a meaningful use of it — a browser with a vanishingly small share of real visits is not worth the same testing investment as one used by a meaningful share of the actual audience.

Where the real target comes from

GA4’s Tech reports (Reports → Tech → Overview, broken down by browser and by device) show exactly which browsers and device categories a site’s own visitors are actually using, over a real measured period. This is the correct starting point for a compatibility brief, replacing a guess with the site’s own measured reality — a business whose visitors are overwhelmingly on mobile Safari and Chrome for Android does not need the same testing investment in a range of older desktop browsers that a business-to-business site with a different audience profile might.

A reasonable baseline for most Australian small-business sites

In the absence of a site’s own data (for a brand-new site with no traffic history yet), a reasonable working assumption for 2026 covers the current and one previous major version of: Safari on iOS, Chrome on Android, Chrome on desktop, and Safari on desktop (macOS) — because these four combinations account for the substantial majority of everyday consumer and small-business web browsing in Australia. A correctly configured viewport meta tag matters as much across these mobile browsers as any CSS or JavaScript feature does, since it is what stops a mobile browser rendering the page as a shrunk-down desktop layout. This is a starting assumption to replace with real data as soon as the site has enough traffic to check it directly, not a permanent substitute for measuring the actual audience.

What “supported” should actually mean

A supported browser does not need to render the site pixel-identically to every other supported browser — expecting that wastes development effort on cosmetic differences that make no functional difference to a visitor. What “supported” should mean, practically: the site’s content is fully readable, every interactive element (forms, navigation, calls to action) works correctly, and no core function is broken. Small differences in font rendering, shadow softness or subtle spacing between browsers are normal and not worth chasing.

Where genuine cross-browser incompatibility still causes real problems

Older browser versions, and some in-app browsers embedded inside social media apps (which sometimes lag behind the standalone browser they are based on), can genuinely fail to support newer CSS or JavaScript features a site relies on. The practical response is not avoiding modern features altogether, but using them with an appropriate fallback where a real, measurable share of visitors would otherwise be affected — a judgement best made against the site’s own Tech report data rather than a blanket rule either way.

Progressive enhancement as the practical answer to “what about older browsers”

Rather than choosing between using a modern feature or avoiding it entirely because some visitors’ browsers might not support it, the established technical approach is progressive enhancement: build the core function to work with a simpler, widely supported technique, then layer a more advanced feature on top for browsers that support it, using feature detection (checking whether a specific capability exists) rather than guessing from a browser name. A browser support table such as caniuse.com is the standard way to check in advance whether Safari, Chrome, Firefox and other browsers actually support a given feature before relying on it. This means a genuinely older browser still gets a working, if plainer, experience, while a modern one gets the enhanced version — rather than the all-or-nothing choice a compatibility brief sometimes assumes is the only option.

In-app browsers are not the same as the full version of the browser they are based on

A link opened inside Instagram, Facebook or a similar app frequently opens in that app’s own built-in browser view rather than the visitor’s actual default browser, and this in-app browser can behave differently from the standalone version — sometimes lagging behind on support for newer web features, and sometimes restricting certain capabilities the standalone browser allows. Because a meaningful share of social media traffic can arrive through exactly this kind of in-app browser, it is worth checking a site specifically inside these apps’ own link previews, not only in the standalone browsers already covered by the Tech report breakdown.

Testing without needing to personally own every device

A small business does not need to physically own an iPhone, several generations of Android phones and multiple desktop operating systems to test compatibility properly — cross-browser testing services exist specifically to provide remote access to real device and browser combinations for exactly this purpose, and using one of these is generally more practical than trying to assemble a personal device library covering every combination identified in the Tech report data.

A short, checkable approach

Step	Why
Pull GA4’s Tech reports for browser and device breakdown	Replaces a guess with the site’s own real visitor data
Set the testing target to the top combinations covering the substantial majority of real traffic	Focuses testing effort where it actually matters
Test core functions (forms, navigation, calls to action) on each target combination	Functional correctness matters more than pixel-perfect visual match
Revisit the target periodically as browser and device usage shifts over time	Compatibility targets are not fixed forever

What to do next

Pull the Tech report for an existing site before setting any compatibility brief for a rebuild or new feature — it replaces guesswork with the site’s own real numbers. For a new site with no traffic history yet, use the four-combination baseline above as a starting point and revisit it once real data exists. Web development services covers where compatibility testing typically sits in a project’s scope.