![Thomas Steiner](https://web.dev/images/authors/thomassteiner.jpg) Thomas Steiner [GitHub](https://github.com/tomayac) [LinkedIn](https://www.linkedin.com/in/thomassteinerlinkedin) [Mastodon](https://toot.cafe/@tomayac) [Bluesky](https://bsky.app/profile/tomayac.com) [Homepage](https://blog.tomayac.com/)

<br />


Published: May 12, 2025

<br />

The proposed HTML `<permission>` element is still in origin trial, as the Chrome team
refines it, building upon the foundation laid in
[our initial origin trial](https://developer.chrome.com/origintrials#/view_trial/4531184175088140289).
This post shares enhancements that aim to provide you with more flexibility and
control when requesting permissions within web applications. For a comprehensive
overview of the `<permission>` element's introduction and its initial
capabilities, refer to our earlier article
[An origin trial for a new HTML `<permission>` element](https://developer.chrome.com/blog/permission-element-origin-trial.md.txt).

> [!TIP]
> **Success:** From Chrome 144 you can use the new [`<geolocation>` HTML element](https://developer.chrome.com/blog/geolocation-html-element.md.txt). This element represents a major shift in how sites request user location data---moving away from script-triggered permission prompts toward a declarative, user-action-oriented experience. It reduces the boilerplate code required to handle permission states and errors, and provides a stronger signal of user intent, which helps avoid browser interventions (like quiet blocks).

## Content support for fallback UX

The `<permission>` element was initially defined as a void element without
content until Chrome 136. From Chrome 137 it supports content, which means it's
now *required* to mark it up with opening and closing tags:

```html
<permission>
  <!-- optional content -->
</permission>
```

This change lets you include fallback user interfaces within the element's
content. These fallbacks are displayed in browsers that don't support the
`<permission>` element or when an unsupported `type` attribute is specified.
This ensures a more graceful degradation and improved user experience across
different browser environments.

```html
<!-- Invalid `type` attribute value -->
<permission type="not-supported">
  <p>Your browser does not support the specified <code>type</code>.</p>
</permission>
```

## More detailed programmatic feature detection

To help you determine support for specific permission types, we've introduced a
static method, `isTypeSupported()`:

```javascript
HTMLPermissionElement.isTypeSupported('geolocation');
```

This method returns a boolean indicating whether the specified permission type
is supported. Combined with the existing feature detection, `typeof
HTMLPermissionElement !== 'undefined'`, you can now programmatically make sure
both support for the `<permission>` element and support for specific permission
types.

Note that you can also pass multiple space-separated permission types (for
example, `"camera microphone"`) and it will return whether the overall string is
a valid `"type"` value. For example, calling `isTypeSupported()` with the
following parameters returns these results:

- `"camera"` → `true`
- `"geolocation"` → `true`
- `"camera geolocation"` → `false` (Even though the types are individually supported, the combination is not.)

## Updated event names

In Chrome 136, we introduced two new events to replace the earlier ones:

- `onpromptdismiss` (replaces `ondismiss`)
- `onpromptaction` (replaces `onresolve`)

These new events provide clearer semantics and better align with the element's
behavior. The older events will be deprecated in Chrome 138, so we recommend
updating your event handlers accordingly.

## Icon support

We're working towards enabling icon support within the `<permission>` element,
targeted for Chrome 138. This feature will let you display predefined icons
corresponding to the permission type, with limited styling options such as color
and size adjustments. The exact API details are still being finalized. ￼

The following examples show the default, a different fill color, and no fill color
but with a black outline.

### Default styling

![Default rendering of the icon.](https://developer.chrome.com/static/blog/enhancements-to-permission-element/permission-icon-default.png)

The default color of the icon is same as the permission element's text color.

### Modified styling

The following examples show exemplary modifications to the default styling.

#### Change of the icon color

```css
::permission-icon {
  fill: black;
}
```

![Modified rendering with solid black icon.](https://developer.chrome.com/static/blog/enhancements-to-permission-element/permission-icon-fill-demo.png)

#### Change of the icon outline

```css
::permission-icon {
  fill: white;
  stroke: black;
  stroke-width: 20px;
}
```

![Modified rendering with black outline icon.](https://developer.chrome.com/static/blog/enhancements-to-permission-element/permission-icon-stroke-demo.png)

### Disable the icon

Once it is launched, the icon will be enabled by default. If you want to disable
the icon, it can be done using the following CSS

```css
::permission-icon {
  display: none;
}
```

## Style guidelines

For comprehensive guidance on styling the `<permission>` element, including best
practices and restrictions, refer to the
[`<permission>` styling guidelines](https://github.com/WICG/PEPC/blob/main/HOWTO.md#applying-style-to-the-pepc).
This resource provides detailed instructions to help you effectively style the
element within your applications.

## Expanded platform and capability support

The `<permission>` element now supports additional platforms and capabilities:

- **Android support:** The element is now functional on Android devices, broadening its applicability across different user platforms.
- **Geolocation support:** You can now request `type="geolocation"` permissions using the `<permission>` element with an additional `preciselocation` boolean attribute. While the `preciselocation` attribute affects only the prompt's wording, we're actively working on differentiating between coarse and precise location permissions in future updates.

## Conclusions

These enhancements to the `<permission>` element are part of our ongoing efforts
to streamline permission requests and improve user experience on the web. We
encourage you to experiment with these new features and [provide
feedback](https://github.com/WICG/PEPC/issues) to help us refine and evolve this
capability.

> [!NOTE]
> **Note:** The end date for the origin trial of the `<permission>` element has been extended to 11th November. The blog post has been updated to reflect that. We've also added a section to show how the icon can be disabled. The example images have also been updated to a higher resolution.