Browser Support Policy

Support decisions should balance real users, maintenance cost, and what your team can actually test.

01 — Purpose

Support policy reflects real users

“Support all browsers” is not a policy — it is a wish that ignores maintenance cost.

A browser support policy balances who actually uses your product, what your team can test, and how much degradation is acceptable on older clients. Write it down so decisions survive turnover and deadline pressure.

02 — Baseline

Define your supported baseline

Be explicit about what “supported” means — fully tested, or best effort.

  • list current versions of Chrome, Firefox, Safari, and Edge you test every release
  • define mobile browsers separately — iOS Safari often diverges from desktop
  • state whether Internet Explorer or legacy Edge are out of scope — with dates
  • align with analytics — review top browsers quarterly and adjust

03 — Enhancement

Progressive enhancement and detection

Older browsers should get a usable experience — not a broken one and not pixel parity.

  • core journeys work without cutting-edge CSS or JavaScript features
  • use feature detection — not user-agent sniffing — for optional enhancements
  • provide fallbacks for grid, container queries, or native dialog where needed
  • document known limitations rather than silent failure

04 — Practice

How the team uses this policy

A policy in a wiki nobody reads is decoration.

  • link the policy from project README or delivery handbook
  • reference it in QA checklists and release readiness
  • revisit when adopting new platform APIs — popover, subgrid, view transitions
  • exceptions logged with owner and expiry — not permanent “temporary” hacks