Client-side testing

Also called: client-side experimentation

Last updated:

Client-side testing is any test or rollout whose variation is decided in the user's own browser or mobile app. A client SDK holds the flag configuration in memory and evaluates it there, so the interface can branch on the result without a round trip to your servers. Code running on someone else's device can be read by whoever owns that device, so everything the SDK receives has to be safe to expose. The key type is what enforces that.

What a client key can see

Featureflip issues two kinds of SDK key, prefixed sdk_client_ and sdk_server_. A client key returns only the flags marked client-side visible, which makes it safe to ship inside a browser bundle. Every other flag in the project stays invisible to it, including the ones whose names alone would give away unreleased work, and because that filter is applied when the configuration is served, an unmarked flag never reaches the device in the first place. The browser SDK reference covers setup and the key type it expects.

What this changes about a test

Deciding on the device makes purely visual changes easy, because the variation is available before anything renders. It also rules out secrecy. A curious user can read the flag payload straight out of the bundle, so a client-side test should carry no credential and no unannounced feature name. Cost behaves differently too, since each device holds its own connection and that is the unit metered by vendors charging per monthly active user. Assignment stays stable throughout, because bucketing hashes the user key deterministically rather than reading anything off the device.

Want the full picture? Read the concept guide: Browser SDK →

Try it in your own app

Free Solo plan covers 10 flags and 2 environments. No credit card, no demo call — sign up and ship.