Cross-Browser Compatibility: How to Test and Fix a Website

The short answer

Modern browsers agree on most standards, but not all of them, and not at the same speed. A site is cross-browser compatible when its key flows work (not necessarily look pixel-identical) in every browser your audience actually uses. The process is simple:

1. Decide which browsers you support.
2. Configure build tools to target exactly that list.
3. Check features before using them, and provide fallbacks.
4. Test on real devices, especially iOS and in-app browsers.

Where browsers still differ

• Safari on iOS and macOS. It ships new features on its own schedule. On iOS every browser, including Chrome, uses the same WebKit engine, so a Safari bug is an iPhone bug. Typical issues: 100vh that ignores the address bar (use dvh/svh units), date and time inputs with a different UI, autoplay restrictions on video, stricter rules for cookies and storage, scroll and position: sticky quirks inside overflow containers.
• Mobile WebViews. Apps like Telegram, Instagram and Facebook open links in an embedded browser. On Android it is usually the system WebView, which may be older than Chrome on the same phone; on iOS it is WebKit. Expect differences in file downloads, popups, window.open, payment flows and safe-area insets. Telegram Mini Apps add their own viewport and theme behavior.
• Older Android devices and budget phones. Slow CPUs expose heavy JavaScript and animations that feel fine on a developer laptop.
• Form controls, fonts and scrollbars. Native rendering differs by platform; style them deliberately or accept the native look.

How to check feature support

Before using a CSS or JavaScript feature, look it up on Can I use or in the compatibility tables on MDN. For anything not supported by all your targets, choose one of three options:

• Progressive enhancement: the page works without the feature and gets better with it.
• Feature detection in CSS or JS, with a fallback.
• Polyfill, if the missing feature is critical.

.grid { display: flex; flex-wrap: wrap; }

@supports (display: grid) {
  .grid { display: grid; grid-template-columns: repeat(3, 1fr); }
}

Set a browserslist target

browserslist is a single config that tells Autoprefixer, Babel, PostCSS, SWC and other tools which browsers to support. Put it in package.json or a .browserslistrc file:

> 0.5%
last 2 versions
not dead
iOS >= 15

Base the list on your real analytics, not on defaults. If many visitors come from Telegram on Android, include the WebView versions they use. Run npx browserslist to see what the query resolves to.

Autoprefixer and polyfills

• Autoprefixer (a PostCSS plugin) adds vendor prefixes like -webkit- only where your browserslist needs them. Do not write prefixes by hand. Many frameworks already include it.
• Transpiling (Babel, SWC, esbuild) converts modern syntax into code older engines understand.
• Polyfills add missing APIs (for example, structuredClone or Intl features). Load only those you need: a targeted import or a differential build is better than shipping a giant bundle to every user.

Remember: transpiling fixes syntax, polyfills fix missing APIs, and neither fixes CSS layout or WebKit rendering bugs.

How to test

A practical minimum: one iPhone, one mid-range Android, desktop Chrome, Safari and Firefox, plus opening the site from inside Telegram and other apps your traffic comes from. For iOS debugging, connect the phone to a Mac and use Safari Web Inspector; for Android, use chrome://inspect.

Common mistakes

• Testing only in Chrome because "everyone uses it".
• Treating DevTools mobile emulation as an iPhone.
• Copying a browserslist config without checking your own analytics.
• Forgetting in-app browsers, where a large share of social traffic lands.
• Fixing a Safari bug with user-agent sniffing instead of feature detection.