---
slug: origin-trial
type: pattern
summary: "A time-boxed mechanism that exposes an experimental web-platform feature to a fraction of real traffic under signed-token consent from participating origins, generating compatibility data before the Intent to Ship gate."
created: 2026-05-12
updated: 2026-05-16
last_link_verified: 2026-05-13
sources_audited: 2026-05-16
related:
  intent-ship-pipeline:
    relation: used-by
    note: "Origin Trial is the mid-pipeline real-traffic feedback stage the pipeline depends on to clear an Intent to Ship."
  origin-trial-tokens:
    relation: produces
    note: "The governance pattern is what authorizes the operational deployment pattern; tokens are the artifact a participating origin receives."
  deprecation-trial:
    relation: complements
    note: "Deprecation Trial is the reverse-direction sibling pattern; the same mechanism gates removal of an existing feature rather than addition of a new one."
  permanent-experiment:
    relation: prevented-by
    note: "Disciplined trial sunset is what keeps an Origin Trial from accreting into a permanent shipping surface; the antipattern is the failure of that discipline."
  zombie-origin-trial:
    relation: prevented-by
    note: "Server-side disablement at trial end is what prevents the operational form of the trial's gate from outliving the trial itself."
  feature-flag-guarding:
    relation: uses
    note: "Every origin-trial feature is gated behind a base::Feature flag the trial enables for the participating origin; the flag is the implementation-side mechanism the trial activates."
  wicg-explainer:
    relation: depends-on
    note: "An Explainer in a WICG or W3C repository is the upstream artifact that names the feature the trial validates."
  stable-trust-boundary:
    relation: enforces
    note: "The trial is what keeps an unvalidated feature out of Stable; the boundary the trial protects is the project's standing claim about Stable suitability."
---

# Origin Trial

> **Pattern**
>
> A named solution to a recurring problem.

*A time-boxed mechanism for exposing an experimental web-platform feature to a fraction of real-world traffic under signed-token consent from participating origins, generating compatibility and usage data before the Intent to Ship gate.*

A feature owner who has finished implementation and passed every unit test still doesn't know how the feature behaves against the open web's full bestiary of CMS templates, third-party scripts, accessibility tooling, and frame embeddings. Origin Trials are how the Chromium project answers that question without flipping the feature on for every Chrome user on Earth. A site operator who wants the feature registers their origin, receives a signed token, includes the token in HTTP response headers or a `<meta>` element, and the feature is enabled only for their origin for the duration of the trial.

## Context

Origin Trials sit between the developer trial (a flag any contributor can flip in a developer build) and the Intent to Ship gate (three API-owner approvals to enable the feature by default for all users). The mechanism's stage in the [Intent to Ship Pipeline](intent-ship-pipeline.md) is the fourth of six. Trials are run by the Chrome team through the Origin Trials portal (`developer.chrome.com/origintrials/`) and tracked publicly on `chromestatus.com`; a feature's trial lifecycle is part of its public record from registration through expiry. The pattern operates at the open-web scale that the Chromium project uniquely sees: a trial generates compatibility data from real production sites that no internal benchmark suite could synthesize.

## Problem

A feature team has working code, an Explainer in a WICG repository, an Intent to Prototype thread on `blink-dev`, and a developer-trial flag that anyone willing to launch Chrome with a command-line argument can flip. None of that gives the team usage data from production sites. The team's next move is to request an Intent to Ship and let the feature reach Stable by default, but no API owner will grant the third LGTM on that thread without empirical evidence that the feature does not break the open web. The recurring problem is how to gather that evidence without exposing the entire stable user population to an unvalidated feature first.

## Forces

- **Real-world fidelity vs. user exposure.** Synthetic test corpora miss the long tail of real-site interactions; exposing every user to an unvalidated feature is the cost the trial mechanism exists to avoid.
- **Site-operator agency vs. project control.** Operators want first-mover access to new platform capabilities; the project needs the trial's enable-set to be opt-in and revocable so a bad feature can be pulled without browser releases.
- **Iteration speed vs. compatibility stability.** Trial features can change syntax and semantics during the trial; sites that build on a trial feature accept that the API may break before it stabilizes.
- **Trial duration vs. data quality.** A short trial misses seasonal traffic patterns and slow-moving CMS deploys; a long trial accretes dependents and raises the cost of any subsequent breaking change.
- **Public accountability vs. operator confidentiality.** Trial enrollment is public on `chromestatus.com`; operators that register an origin become visible to competitors, security researchers, and the press.

## Solution

The Chromium project gates exposure of an experimental web-platform feature behind a per-origin, time-boxed registration with a cryptographically signed token. The sequence:

1. **Feature team** registers a trial through the project's process: the feature already has an Explainer, an Intent to Experiment approval on `blink-dev`, and a `base::Feature` flag wired through the renderer. The team specifies the trial's duration (typically six to eighteen weeks aligned to milestone boundaries), the per-feature gating behavior at expiry, and the data the trial will collect.
2. **Site operator** visits the Origin Trials portal, picks the feature, names the origin (scheme + eTLD+1 + port), accepts the trial terms, and receives a signed token bound to that origin and that feature with an explicit expiry.
3. **Site operator** deploys the token via the `Origin-Trial` HTTP response header on documents served from that origin, or via a `<meta http-equiv="origin-trial" content="...">` element in served HTML.
4. **Chrome client** verifies the token's signature, checks that the origin in the token matches the document's origin, checks that the trial is currently active, and flips the per-document feature flag.
5. **At trial end** the Chrome team disables the trial server-side. Tokens issued for the trial stop verifying; the underlying `base::Feature` falls back to its default (off, unless an Intent to Ship has authorized default-on shipping by then).

What makes the pattern work is the asymmetry between the cost of enabling a feature for an opted-in origin and the cost of enabling it for every user. A site that participates in a trial has accepted the risk; the project gathers usage data from that population without affecting any user who did not opt in. The data feeds the Intent to Ship thread.

## How It Plays Out

A team at an enterprise browser vendor is asked to evaluate whether to enable a new web-platform feature in their downstream fork's next milestone. The feature is mid-trial in upstream Chromium. The team reads the `chromestatus.com` entry, follows the link to the Origin Trial portal, and sees the registered origins, the trial's duration, and the team's stated rollout plan. They follow the `blink-dev` link to the Intent to Experiment thread and read which API owners expressed concerns. They observe that the trial expires before the fork's planned release and that no Intent to Ship has been filed. The team's decision: defer enabling the feature in the downstream fork until the trial has closed, the Intent to Ship has cleared three API-owner LGTMs, and the feature has shipped by default to Stable. The fork avoids becoming a population that depends on a feature that may not ship.

A second team is the upstream feature team itself. They run an Origin Trial through Chrome 124-127 and accumulate seven thousand registered origins. Three weeks into the trial, a participating origin files a compatibility report: the feature breaks the same site's existing accessibility tooling. The team can isolate the cause to a specific interaction with the AT-SPI bridge on Linux, fix it in Canary, and ask the affected origin to re-register against the corrected build. The same regression in Stable would have produced an unrecoverable accessibility incident affecting every desktop Linux Chrome user. The trial caught it because the participating origin had pre-existing accessibility tooling the team's internal test corpus did not include.

## Consequences

**Benefits.** The Intent to Ship thread arrives at the API-owner gate with named participating origins, recorded compatibility reports, real traffic numbers, and a concrete operator-side experience report. API owners read that record when deciding whether to grant the LGTM. Site operators get first-mover access to new capabilities and a structured channel for filing compatibility issues. The open-web population that did not opt in carries none of the risk.

**Liabilities.** Trials are slow. A feature that could ship in days under the project's earliest-stage process takes a milestone-aligned trial window plus the Intent-to-Ship discussion before it reaches Stable. Trials also generate dependents. Site operators who deploy a trial token build production code against a feature that may never reach Stable; the cost of that bet is borne by the operator, but the project pays the social cost when a popular trial is cancelled. The mechanism's most visible failure mode is the [Experiment That Became Permanent](permanent-experiment.md), the upstream antipattern in which a popular trial accretes so many dependents that the project cannot bring itself to disable it at the trial's stated end date. The operational counterpart on the deployment side is the [Zombie Origin Trial](zombie-origin-trial.md), which names the failure mode of a trial whose server-side disablement was never executed.

The pattern doesn't guarantee good features. It guarantees that the Intent to Ship gate operates over real-world evidence rather than internal projection. A feature that performs well in a trial may still fail at Stable scale; a feature that struggles in a trial may have struggled with the wrong opted-in population. What the trial guarantees is that the project, the API owners, the standards-body participants, and the downstream consumers are all reading the same public record of the feature's behavior against opted-in production traffic.

## Notes for Agent Context

When an AI coding agent is asked to add a web-platform feature gated behind an Origin Trial, the agent must wire the runtime check through `blink::origin_trials::IsFeatureEnabled()` (or the per-renderer equivalent), not check the `base::Feature` flag directly. Direct flag checks bypass the token-verification path and produce features that activate for opted-in origins but also fire under the developer-trial flag, which isn't the deployment semantic the trial requires. The agent must also surface the trial's expiry date and the feature's post-trial fallback behavior in the change description; an Origin Trial without a planned disposition at expiry is the upstream of the [Experiment That Became Permanent](permanent-experiment.md) antipattern. Refuse to mark a trial implementation complete without a registered expiry, a planned Intent to Ship calendar slot, and a fallback path for tokens that outlive the trial.

## Sources

The Origin Trials framework was designed at Google by Jason Chase (`chasej@chromium.org`), whose 2016 [*Origin Trials Framework Design Outline*](https://docs.google.com/document/d/1qVP2CK1lbfmtIJRIm6nwuEFFhGhYbtThLQPo3CSTtmg/edit) is the founding design document; Chase has continued to lead the Chrome team that operates the framework, named that way in his [Chrome Dev Summit 2019 speaker bio](https://developer.chrome.com/devsummit/schedule/480407ea47efd1aa2d14fb007fee6f36). The framework's conceptual origin is Alex Russell's Medium essay [*Doing Science on the Web*](https://medium.com/@slightlylate/doing-science-on-the-web-af26d9be2faa), which the official Chrome [Origin Trials explainer](https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/explainer.md) cites by name and which supplies the medical-trial analogy ("first do no harm; start with a small population and iterate") the mechanism's name and per-origin opt-in geometry directly inherit. The framework is also explicitly a response to the vendor-prefix experience the web platform ran through CSS during 2010-2012; Peter-Paul Koch's [*CSS vendor prefixes considered harmful*](https://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref.html) (QuirksMode, March 2010), Henri Sivonen's [*Vendor Prefixes Are Hurting the Web*](https://hsivonen.fi/vendor-prefixes/), Eric Meyer's [*Vendor Prefix Predicament* interview with Tantek Çelik](https://alistapart.com/article/the-vendor-prefix-predicament-alas-eric-meyer-interviews-tantek-celik/) (*A List Apart*, 2012), and Russell's own [*Vendor Prefixes Are A Rousing Success*](https://infrequently.org/2011/11/vendor-prefixes-are-a-rousing-success/) are the canonical contemporaneous critiques that motivated the redesign.

The cross-engine generality of the mechanism, that the same per-origin signed-token shape now operates in three engines rather than one, is recorded by Mozilla's parallel program at [`wiki.mozilla.org/Origin_Trials`](https://wiki.mozilla.org/Origin_Trials) and by Microsoft Edge's Origin Trials documentation; both projects adopted the Chromium framework's shape and name. The Chromium process documentation maintained by the Chrome team at [`developer.chrome.com/docs/web-platform/origin-trials/`](https://developer.chrome.com/docs/web-platform/origin-trials/) and [`www.chromium.org/blink/origin-trials/`](https://www.chromium.org/blink/origin-trials/) is the canonical operator-facing reference. The [`chromestatus.com`](https://chromestatus.com/) per-feature view is the source of truth for trial lifecycle data; the [`blink-dev`](https://groups.google.com/a/chromium.org/g/blink-dev) mailing-list archive and the [`experimentation-dev`](https://groups.google.com/a/chromium.org/g/experimentation-dev) archive carry every Intent to Experiment and Intent to Ship thread that has gated a trial.

## Technical Drill-Down

- [Origin Trials developer documentation](https://developer.chrome.com/docs/web-platform/origin-trials) — the site-operator's process surface; token registration, deployment forms, and the third-party token mechanism are documented here.
- [Origin Trials portal](https://developer.chrome.com/origintrials/) — the registration interface; the list of active and recent trials is public.
- [`chromestatus.com`](https://chromestatus.com/) — the per-feature state machine; each trial's start, end, and milestone alignment is queryable.
- [`blink-dev` archive](https://groups.google.com/a/chromium.org/g/blink-dev) — the authoritative record for Intent to Experiment and Intent to Ship threads that gate trial entries and exits.
- [Web Incubator Community Group (WICG)](https://wicg.io/) — the community-group home for the Explainers that name the features trials validate.

---

- [Next: Deprecation Trial](deprecation-trial.md)
- [Previous: Three-LGTM API Owner Gate](three-lgtm-gate.md)