Browser support

A fixed, dated floor for every shipped asset — checkable by a gate, and it does not move under your feet.

The promise

The Userz browser SDK (@userz-ai/browser, @userz-ai/react and the CDN script tag) supports browsers released since 2023: Chrome/Edge 120+, Firefox 120+, Safari 17+.

That is Baseline 2023. The floor is a fixed set of versions, not a rolling “last N majors”: a browser that is supported today stays supported until this page changes, and this page changes only by a recorded decision — it can be lowered if you need an older browser, never silently raised.

What the floor means

Name	Type	Description
Chrome / Edge	120+	December 2023 and later, including Chromium-based Edge of the same version.
Firefox	120+	November 2023 and later.
Safari	17+	macOS and iOS Safari 17 (September 2023) and later; iOS WebViews follow the iOS version.

Every shipped asset — the npm entry points, the script-tag core, each lazily loaded chunk and the all-in-one bundle — is compiled to one target list that names exactly these versions and ES2022. There is no second list anywhere in the build: the floor the docs promise and the floor the compiler emits for are the same constant.

How it is enforced

Syntax. Every built artefact is syntax-checked against the target on every change. A construct the floor cannot parse fails the build, not your users.
Behaviour. The SDK's browser journeys run on Chromium on every change and on Firefox and WebKit on the full matrix.
Above the floor. Newer platform features (the Popover API, constructed stylesheets, fetchLater(), soft-navigation vitals) are used only behind feature detection with a complete fallback. A supported browser that lacks one of them gets the fallback, never a broken widget.

A WebKit run is not a Safari claim. The promise names Safari versions; the matrix names WebKit builds. The Safari floor is held by the compile target and the syntax check, which are exact, and by WebKit journeys, which are indicative.

Below the floor

A browser older than the floor may fail to parse the SDK at all. That is a silent failure: the widget does not mount and no telemetry is sent from that browser, and nothing else on your page is affected — the SDK is loaded async and never blocks your own scripts. If a meaningful share of your users is below the floor, tell us; lowering it is a decision we can make, and the syntax check will then hold the lower target.

Known gaps inside the floor

Firefox before 133 does not support fetch with keepalive. The page-teardown flush falls back to sendBeacon there, and a batch the beacon refuses is kept for the next page load.
Plain http:// pages have no crypto.randomUUID (secure contexts only); event ids are minted with a fallback so those pages still report.