Origin Trials
Origin trials let you ship experimental browser APIs to real users without them doing anything. Here is how they work, what happens when they expire, and whether you should use them in production.
Most experimental features in software keep users locked out until the feature ships officially. Origin trials flip that model.
The developer opts in. The users get the feature automatically.
Beyond Green and Light-Green
The maturity tiers covered in the previous post described green and light-green APIs -- stable and Chromium-only respectively. There is a third tier below both of those: APIs that aren't available in any production browser yet.
These APIs are unstable by definition. The function names, parameter shapes, and behaviors might change before they ship. Some never ship at all. You can't just call them and expect them to work -- you need to explicitly opt in.
Browser flags are one way. Origin trials are the other, and the more interesting one.
Flags: Just for You
Every major browser has a flags page.
Chrome and Edge: chrome://flags and edge://flags. Safari: the Develop menu (Mac only) under "Experimental Features." Enabling a flag turns on an experimental API for that browser instance, on that device only.
This is perfect for local exploration. You want to see what the Popover API looks like before it ships? Enable the flag, poke around, form an opinion.
It is useless for production. Your users aren't enabling flags. The feature only exists for you.
Origin Trials: Testing with Real Users
Origin trials solve a real problem. Testing an API in your local browser tells you very little about how it performs under real conditions -- varied devices, real network situations, actual usage patterns. Flags cannot help with that.
An origin trial ties an experimental API to a specific domain. Any Chrome user who visits that domain gets access to the API automatically, no flags, no settings, no user action required. The developer accepted the instability risk. The users just get the feature.
The setup has four steps:
- Go to the active trials list and find the API you want to test
- Register your domain -- you log in with a Google account and submit a form
- Receive a unique token tied specifically to your origin
- Embed the token in your HTML as a
<meta>tag or HTTP response header
<meta http-equiv="origin-trial" content="YOUR_TOKEN_HERE">From that point, Chrome users visiting your origin get access to the experimental API automatically -- for the duration of the trial.
ExpandOrigin Trial Lifecycle
The Expiry Problem
Every origin trial has an end date. When it expires, one of three things happens:
- Ships as stable. The API worked well enough. It becomes a standard browser feature -- no token needed going forward. This is the best outcome.
- Goes to a new trial. The team wants to adjust the spec based on feedback. A revised trial opens with a new token and a revised API shape.
- Gets removed. The API didn't pan out. It disappears from Chrome entirely. If your production code depended on it, the feature silently breaks.
That third outcome is the real risk of using origin trials in production. You are shipping a feature with an expiry date. When the trial ends, you need a plan.
The correct approach is to treat origin trial features the same way you'd treat a feature behind feature detection -- always build the non-capability path first, and layer the experimental feature on top. If the trial ends and the API disappears, the base experience still works.
Edge and Firefox Trials
Origin trials started as a Chromium initiative, but the pattern has spread.
Edge runs its own origin trials separately from Chrome's. Edge's trials tend to focus on Windows-specific and desktop PWA features -- things like native window management and taskbar integration that matter more on desktop than mobile. A Chrome token won't work for Edge-specific trials, and vice versa.
Firefox has recently started its own origin trial program too, though it covers far fewer APIs than Chrome's at this point.
Safari has no equivalent. Experimental Safari features stay behind the Develop menu flag until Apple decides to ship them as stable. There is no way to enroll your site to give Safari users access to an unshipped feature.
Who Should Use Origin Trials
Origin trials are not for most production features. The instability risk is real -- every trial is a bet that the API ships.
They make sense when:
- You want genuine production-scale feedback on a capability before it stabilizes
- The capability is additive and the base experience works without it
- You are tracking the trial end date and have a fallback plan
For the APIs covered in the rest of this series, the interesting ones are mostly green or light-green. Anything still behind a trial gets flagged explicitly so you know what you're dealing with.
There is one more tier below experimental -- capabilities the web will probably never expose at all. Not because the technology doesn't exist, but because any website could silently use them. That's where red APIs come in.
The Essentials
- Browser flags enable experimental APIs for one device only -- useful for personal testing, not production.
- Origin trials tie an experimental API to your domain via a token. Chrome users get access automatically -- no flag, no user action. Register at
chrome-origin-trials.appspot.com. - Every origin trial expires and has three possible outcomes: stable, revised trial, or removed. Using one in production without a fallback means accepting the risk that your feature silently breaks when the trial ends.
Further Reading and Watching
- What are Chrome's origin trials? (Chrome for Developers) -- short official explainer from the Chrome team on how origin trials work
- Chrome Origin Trials -- developer.chrome.com -- full documentation including the active trials list and registration steps
Keep reading