Permissions request chip

The permissions UX until now

When a user visits a site that requests a permission, a bubble pops up to prompt the user to make a decision. For example, below you can see the geolocation permission prompt as implemented in Chrome up to version 96. (You can try this and other permissions on our demo site

Chrome geolocation permission prompt

Most permission prompts are ignored or dismissed

Chrome's telemetry data proves that a lot of permission prompts are ignored. You can explore the notification permission data in the Chrome UX report yourself. For now, consider the table below that shows how Windows users reacted to the notification prompt on sites in an accumulated way, while noting that geolocation prompts saw a similar dismiss or ignore behavior.

Action Percent of notification prompts
Allow 6.69%
Block 9.20%
Dismiss 35.76%
Ignore 47.19%

Given an ignore/dismiss rate of approximately 85%, and especially given how much the prompt stands out and insists on users making a decision immediately, there is a conflict between the level of urgency assumed by the browser versus the user's preference for waiting to make a decision. This creates the perception that it's "annoying" for a site to ask for a permission because it will be lost in the potential extra things users need to react to like cookie consent banners, newsletter signups, etc.

New design

From Chrome 98 on, we therefore introduced an animated chip UI which appears next to the lock whenever a permission is requested. This consists of an icon and label describing the permission being requested. Our aim was to improve the experience of web browsing while avoiding permission requests that are generally unnecessary for the vast majority of users and frequently ignored or dismissed.

The existing prompt bubble will be shown when the request chip is clicked (if not already shown) and the request UI is automatically augmented with the request bubble based on the heuristics listed below:

  • The permission was triggered through a user gesture when interacting with the site itself rather than automatically triggered by the site.
  • The permission is deemed essential and generally non-spammy. Currently this includes camera, microphone, and camera paired with microphone.

Flow diagram going from padlock to the geolocation prompt, which, if dismissed, results in the 'geolocation blocked' icon, which, after a four second delay, is finally replaced with the padlock again.

Forcing the new design

Since this is a staged rollout, you can force the new design by toggling the following flags:

  • chrome://flags/#permission-chip
  • chrome://flags/#permission-chip-gesture
  • chrome://flags/#permission-chip-request-type

Flow of the new design

Without user gesture

For non-essential permissions not triggered by a gesture, the prompt no longer intrudes on the site contents, and does not insist on an immediate decision. The user can ignore the request chip until they have enough information to make a decision.

Without interaction

With no interaction, and after a short delay, the request chip will automatically collapse to just a blocked icon (to indicate the permission being temporarily blocked), before being dismissed entirely. The aim is to get out of the way of users who choose not to make a decision letting them do so without any interaction.

Flow diagram going from padlock to the unobtrusive geolocation chip, which, after a twelve second delay results in the 'geolocation blocked' icon, which, after a four second delay, is finally replaced with the padlock again.

Expected short-term impact

In the short term, and until users get used to the new UI, it is likely that site owners will observe lower grant rates for sites, especially for those that auto-request permissions without priming or demanding a user gesture (which is considered a bad practice anyway). This acknowledged downside is vastly outweighed by the less interruptive experience.

Best practices

It is up to the site to ensure it provides the necessary context and only requests permissions at the appropriate and expected moment. Permissions that have been temporarily blocked—through a user ignoring the request or dismissing the prompt—can request the permission again within the same session. Only do this if the permission is essential for the site or feature to work, otherwise it runs the risk of annoying users and getting auto blocked. In those cases we show the quiet messaging that was introduced in Chrome 80. For more general guidance, see Permission UX.

Outlook and conclusions

There are plans for further UI and UX improvements. The Chrome team is already working on them and investigating potentially more aggressive auto-blocking of permissions based on prior behavior. You will learn about the news here once these plans mature.

Concluding, the new UI reduces the perceived insistence on a decision and improves the browsing experience. Since most permission prompts are blocked or ignored, the met objective was to improve the general experience of browsing, while not breaking user flows when showing a permission prompt, especially in situations where permissions are required to complete a use case.


Hero image by Sigmund on Unsplash. This article was reviewed by Joe Medley.