Cross-Browser & Platform Compatibility Markdown Table Template
A browser support table is a promise with a scope. It tells users which browsers the product is built and tested for, tells QA what to put in the test matrix, and tells support staff what to say when a customer on an old iPad reports a broken page. For a front-end library it also tells adopting teams whether the package will raise the minimum browser requirements of their own app.
Edit This Template
Edit cells, add rows, or sort — the Markdown updates livePaste cells from Excel or Google Sheets into the first header to replace the table · Tab / Enter / arrows move · Shift+F10 opens row & column actions
When to Use This Table
The decisions it drives are concrete. Engineers use it to decide whether they may ship CSS :has() or the Popover API without a fallback. Build tooling uses the same list to choose how much to transpile and which vendor prefixes to add. Product and sales use it to answer procurement questionnaires, which frequently ask for exact minimum versions. Every row you add costs testing time, so the table is also a budget.
A good table is derived from evidence — your own analytics and the features the code actually relies on — and is written in the same terms as the build config, usually a Browserslist query or a Baseline target. It distinguishes engines from brands, treats iOS as its own platform, and dates itself. A bad one carries minimum versions copied from a template years ago that nobody has tested since.
What Goes in Each Column
| Column | Alignment | What to put here |
|---|---|---|
| Browser | left :--- | The product name users recognise, split by platform where behaviour differs: “Safari (macOS)” and “Safari (iOS / iPadOS)” deserve separate rows. Keep Chrome on Android separate from desktop Chrome if your app depends on touch, viewport, or file-picker behaviour. |
| Engine | center :---: | The rendering engine and JavaScript engine pair: Blink / V8, Gecko / SpiderMonkey, WebKit / JavaScriptCore. Engines, not brands, decide compatibility, so this column explains why Edge, Opera, and Brave behave like Chrome. Centered because the values repeat and readers compare them vertically. |
| Minimum Version | center :---: | The oldest version you test and fix bugs for, in backticks with a trailing +. Derive it from a Baseline target or a Browserslist query instead of picking a number, and update it on a schedule. For evergreen browsers, “last 2 versions” is often more honest than a fixed number. |
| Status | center :---: | A support tier in words — Full, Partial, Best effort, Not supported — optionally preceded by a symbol. Never rely on a check mark or colour alone; screen readers and plain-text renderings need the word. Define each tier in a sentence under the table. |
| Platform Notes | left :--- | Known differences and workarounds that affect users: permission prompts, storage limits, features missing in that engine, or a required polyfill. Write the user-visible effect (“paste needs a click first”) rather than the internal cause alone. |
How to Fill It In
- 1Pull ninety days of browser and version data from your own analytics, broken down by operating system. Your users are not the global average; an internal enterprise tool and a consumer mobile app have very different tails.
- 2List the web platform features the code depends on and look each one up on MDN’s compatibility tables or Can I use. The newest feature without a fallback sets your real minimum version.
- 3Encode the policy as a Browserslist query in
.browserslistrcorpackage.json, then runnpx browserslistto print the versions it resolves to. Fill Minimum Version from that output so docs and build agree. - 4Run your end-to-end tests on all three engines. Playwright ships Chromium, Firefox, and WebKit builds, which catches most engine differences; confirm iOS-specific behaviour on a real device or a device cloud.
- 5Write the notes from bugs you have actually seen, add a “last verified” date under the table, and repeat the review at least twice a year.
Ready-to-Paste Variations
Baseline-based support policy
Instead of hand-picked versions, tie support to a Baseline target. The resolved versions below are what baseline widely available returned in Browserslist in October 2026; they move forward over time.
| Browser | Engine | Minimum (Baseline Widely available) | Status |
| :--- | :---: | :---: | :---: |
| Chrome / Edge | Blink / V8 | `123+` | Full |
| Firefox | Gecko / SpiderMonkey | `124+` | Full |
| Safari (macOS) | WebKit / JavaScriptCore | `17.4+` | Full |
| Safari (iOS / iPadOS) | WebKit / JavaScriptCore | `17.4+` | Full |
| Older versions | — | — | Best effort |Feature-level compatibility matrix
For a library README, list the features you depend on with the first version that supports each. The highest number in each column becomes your minimum.
| Feature | Chrome | Firefox | Safari | Fallback |
| :--- | :---: | :---: | :---: | :--- |
| `navigator.clipboard.writeText()` | 66 | 63 | 13.1 | Manual copy button with selected text |
| `structuredClone()` | 98 | 94 | 15.4 | JSON round-trip for plain data |
| CSS container size queries | 105 | 110 | 16 | Media queries |
| CSS `:has()` | 105 | 121 | 15.4 | Extra class set from JavaScript |
| Popover API | 114 | 125 | 17 | Dialog component |Support tiers
Defines what each status word promises, so the main table can stay short.
| Tier | What it means | How we test |
| :--- | :--- | :--- |
| Full | Every feature works; bugs are fixed before release | Automated E2E on every pull request |
| Partial | Core tasks work; named features are unavailable | Manual check before each release |
| Best effort | Content is readable; no guarantees for interactive features | Not tested |
| Not supported | We may block or warn | Not tested |Common Mistakes
Publishing minimum versions nobody tests, such as Chrome
90+in 2026.Chrome 90 shipped in 2021. Either test it, or raise the minimum to what your test matrix and build target cover. A claim you never verify becomes a support liability.
Treating Chrome or Firefox on iPhone as Blink or Gecko.
On iOS and iPadOS, third-party browsers have historically been required to use WebKit, and in most countries they still are; even where other engines are now allowed, few browsers ship one. Give iOS its own row and base its minimum on the WebKit version, which follows the OS version.
Ignoring that Safari is updated with the operating system.
Users on devices that cannot install the latest iOS stay on that release’s Safari. Check your analytics for iOS versions, not just Safari versions, before raising the minimum.
Calling privacy browsers “verified compatible” without testing their defaults.
Brave Shields and similar blockers can stop third-party scripts and randomise fingerprintable APIs such as canvas readback. Test with protections on and list what degrades in Platform Notes.
Keeping the docs and the build target separate.
If the table says Safari 15 but the bundler targets Safari 16.4, one of them is wrong. Generate the table from the Browserslist query, or check both in the same review.
Related Markdown Table Templates
Browse all 50 templatesGit Workflow & Branching Governance
Define branching conventions, source bases, pull request targets, required approval reviews, and CI automation gates.
Hardware & System Prerequisites
Hardware, operating system, runtime, and network specifications required to run software in dev vs production.
Security Advisory & CVE Vulnerability Matrix
Track security advisories, CVE identifiers, CVSS v3 ratings, affected library versions, patched releases, and remediation guidance.
Cross-Browser & Platform Compatibility: Frequently Asked Questions
What does Baseline mean?
Baseline is a status from the WebDX Community Group shown on MDN and web.dev. A feature is “Newly available” once it works in the current Chrome, Edge, Firefox, and Safari on desktop and mobile, and “Widely available” thirty months after that.
Do I need separate rows for Edge, Opera, and Brave?
Not for engine compatibility, since all three use Blink and usually trail Chrome closely. Add a row only when you have seen a real difference, such as an extension, a privacy feature, or an enterprise policy that changes behaviour.
What does the Browserslist defaults query include?
defaults expands to > 0.5%, last 2 versions, Firefox ESR, not dead. It is a reasonable starting point, but it is based on global usage data, so check it against your own analytics before you publish it as policy.
Should I support Firefox ESR?
If you sell to enterprises, schools, or governments, probably yes. Extended Support Release builds receive security fixes but stay on one feature set for about a year, so they lag the regular Firefox release by several versions.