Contact emails
lemi...@google.com,
tun...@google.com
Explainer
https://github.com/WICG/PEPC/blob/main/usermedia_element.md
Specification
https://wicg.github.io/PEPC/permission-elements.html
Summary
Usermedia Capability Element, is a declarative, user-activated control for accessing the starting and interacting with media streams.
This addresses the long-standing problem of permission prompts being triggered directly from JavaScript without a strong signal of user intent. By embedding a browser-controlled element in the page, the user's click provides a clear, intentional signal. This enables a much better prompt UX and, crucially, provides a simple recovery path for users who have previously denied the permission.
Note: This feature was previously developed and tested in an Origin Trial as the more generic <permission> element. Based on feedback from developers and other browser vendors, it has evolved into capability-specific elements to provide a more tailored and powerful developer experience.
Blink component
Public Trackers > Chromium Public Trackers > Chromium > Internals > Permissions > PermissionElement
Web Feature ID
permissions
Motivation
The current web permission model for interacting with user media relies on JavaScript-triggered prompts, giving the user agent no strong signal of user intent. This results in out-of-context prompts, user frustration, and difficult-to-recover-from denial states.
We propose the <usermedia> element, or a suite of elements. This will be semantic HTML control with browser-controlled content and strict styling constraints. These constraints are fundamental to the security model, ensuring a very high level of confidence in the user's intent when making a permission decision at both the site and OS level.
Crucially, the <usermedia> element evolves beyond simply managing permissions; it streamlines the entire journey by also facilitating starting and interacting with media streams. This often eliminates the need for separate JavaScript API calls, simplifying implementation and creating a more seamless user flow.
By providing a clear, consistent, in-page control, this element solves significant user problems related to context blindness and "permission regret," offering a simple recovery path from a previously denied state. The combination of a user-initiated element and a subsequent browser-controlled confirmation UI enhances intent capture, improves accessibility, and prevents manipulative patterns, providing a significantly better experience for both users and developers.
Initial public proposal
https://github.com/WICG/PEPC/issues/62
TAG review
https://github.com/w3ctag/design-reviews/issues/1079
TAG review status
Issues addressed
Origin Trial Name
UserMediaElement
Goals for experimentation
This Origin Trial serves two primary purposes: ensuring continuity for existing partners who have successfully integrated this pattern, and providing a platform to validate and iterate on the new, capability-specific <usermedia> element.
While our previous Origin Trial for <permission> provided strong evidence for the core user-initiated model, feedback from developers and browser vendors prompted us to evolve the design. This new trial is essential for gathering insights on a refined, data-centric API shape to help us reach cross-browser consensus.
To ensure a seamless transition and prevent disruption for our valued OT partners, this trial will initially launch with an API shape that is functionally equivalent to the previous <permission> trial, simply using the new <usermedia> element name. This provides a stable foundation from which we will iterate based on further discussion.
Our goal is to evolve this element towards our proposed data-centric design (
https://github.com/WICG/PEPC/blob/main/usermedia_element.md). However, we recognize that this more advanced API has raised compatibility and complexity concerns with developers (
https://github.com/WICG/PEPC/issues/62). Therefore, a primary objective of this trial is to work closely with the community to address these concerns and refine the final API.
TPAC WebRTC minutes
https://www.w3.org/2025/11/11-webrtc-minutes.html#551
Chromium Trial Name
UserMediaElement
Origin Trial documentation link
https://github.com/WICG/PEPC/blob/main/usermedia_element.md
WebFeature UseCounter name
kHTMLPermissionElement
Risks
Debuggability
The element raises issues to the devtools issues panel which help developers debug issues with their usage of the element.
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No
The element is not supported on Android WebView as it requires permission manager support to function and the WebView permission manager defers most permission decisions to the embedder by design.
Yes
https://wpt.fyi/results/html/semantics/permission-element/usermedia
DevTrial instructions
https://github.com/WICG/PEPC/blob/main/HOWTO.md#enabling-usermedia
Flag name on about://flags
No information provided
Finch feature name
UserMediaElement
Rollout plan
Will ship enabled for all users
Requires code in //chrome?
True
Tracking bug
https://crbug.com/443013457
Availability expectation
Feature is available only in Chromium browsers. We are not aware of other browsers adoption.
Adoption expectation
Feature is used by specific partner(s) to provide functionality within 12 months of launch in Chrome. Partners who are tested the feature in OT are expected to continue usage.
Adoption plan
We are planning to publish on
developer.chrome.com and do further partner outreach
Non-OSS dependencies
Does the feature depend on any code or APIs outside the Chromium
open source repository and its open-source dependencies to
function?
No
Estimated milestones
| Shipping on desktop | 149 |
| Origin trial desktop first | 144 |
| Origin trial desktop last | 148 |
| DevTrial on desktop | 144 |
| Shipping on Android | 149 |
| Origin trial Android first | 144 |
| Origin trial Android last | 148 |
| DevTrial on Android | 144 |
Anticipated spec changes
Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github
issues in the project for the feature specification) whose resolution
may introduce web compat/interop risk (e.g., changing to naming or
structure of the API in a non-backward-compatible way).
This is an MVP launch. The MVP feature is fully functional and used by developers right now. We are working closely with the WebRTC on post-MVP features, the open topics will based on the foundation of the MVP, that we agreed upon with the WebRTC.
Some of the open topics are for example: In the future, we might want to add a parameter to the getUserMedia algorithm so that the algorithm can determine whether the getUserMedia is called from the <usermedia> element or getUserMedia API. Potential to add additional attributes for <usermedia> interface.
We're putting finishing touches on the spec now, work-in-progress PR is here, but once that lands we want to ship for M149 so wanted to start the discussion now.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4926233538330624?gate=6467532078841856
Links to previous Intent discussions
Intent to Prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/692719de.050a0220.17ec37.00c3.GAE%40google.comIntent to Experiment:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6942ed09.050a0220.1050d6.0961.GAE%40google.com