- Introduction
- User Problem
- Goals
- Non-Goals
- Proposal
- Considered Alternatives
- References and Acknowledgements
This proposal introduces an extension of the permission element to support clipboard read permissions (clipboard-read). The goal is to make clipboard access predictable, recoverable, and user-friendly by allowing developers to declaratively request permissions in context, using clearly labelled, browser-controlled UI affordances.
// Example html code
<permission type="clipboard-read"></permission>This explainer outlines how the dedicated permission element model can bring clarity and consistency to clipboard interactions, building upon the same foundation as camera and microphone permissions.
Users encounter clipboard permission prompts while performing actions like copy or paste on the web based on the state of the permissions. However, these prompts are frequently misunderstood, dismissed, or denied—sometimes accidentally, sometimes intentionally, and often due to unclear messaging. Once denied, clipboard operations silently fail with no further guidance, leaving users confused about what went wrong.
The lack of intuitive messaging and the complexity involved in re-enabling permissions results in a frustrating and broken user experience. Users are often unaware that their copy/paste action failed due to permission denial, and even when they realize it, they struggle to locate the settings needed to restore clipboard access.
This creates a recurring failure loop—where the application’s functionality appears broken, and the user is left without any actionable recovery path.
User anecdote:
“I had a window pop up on a website where I was copying text and pictures to my clipboard. The popup window said something about the clipboard, and I mistakenly clicked block. Now I can no longer copy pictures to my clipboard on this website. How do I un-block the clipboard function on this website?” Source: How do I unblock the clipboard for a website - Microsoft Q&A
The table below outlines user problems and scenarios, mapped to their intent to use the clipboard and the corresponding permission state at that moment.
| Clipboard working on site | Clipboard not working on site (site or OS permission missing) | |
|---|---|---|
| Intent to use clipboard on site | ✅ True positive: Intent correctly captured. | ❌ False negative: User intended to use clipboard but permission is blocked (Site/OS) or they changed their mind. Solution: Clear intent by clicking the <permission> element to show the prompt again. |
| No intent to use clipboard on site | ❌ False positive: Permission granted without user intent. Solution: <permission> element requires explicit user click on clearly labeled button to show prompt. |
✅ True negative: Intent correctly captured. |
-
Improve User Clarity Around Clipboard Permission Prompts: Help users better understand why clipboard read access is being requested, so that they can make informed choices when prompted by the browser
-
Enable User Recovery Paths for Denied Clipboard Permissions: Offer UI affordances or mechanisms that let users easily reverse an accidental "Block" decision, either directly in the browser or through app-driven nudges.
-
Align Clipboard Permission UX with Broader Web Permissions Model Ensure that improvements to clipboard permission flows are consistent with the evolving privacy and permissions architecture of the web platform.
-
The proposal will not introduce a way to bypass explicit user permission for clipboard reads, nor will it reduce privacy protections around clipboard access.
-
The scope of this proposal is limited to read access via the Clipboard API; it does not include any modifications to the flow of clipboard write permissions.
We propose supporting a new permission type for the HTML element:
clipboard-read: Allows reading from the user's clipboard.
This element will behave similarly to microphone/camera permission buttons but are tailored to the paste UX.
// Example html code
<style>
permission {
background-color: lightgray;
color: black;
border-radius: 10px;
}
</style>
<permission type="clipboard-read"></permission> 
-
Standard UI:
-
UI When permission is already granted:
-
UI When permission is denied:
This approach extends the permissions API with a request () function that accepts and HTML element as an anchor for positioning the permission prompt.
<p id="pepc_anchor">This is where the permission prompt will be anchored</p>
<script>
navigator.permissions.request(
{ name: 'geolocation' },
document.getElementById('pepc_anchor'),
);
</script> - Adress prompt positioning for better user experience and getting out of failure loop.
- It doesn’t provide robust user intent as a user click can’t be assured, leaving the doors open to abuse by malicious sites.
We considered modifying the regular, usage-triggered permission flow to allow users to recover from blocked states.
- Streamlines the user journey by enabling reconsideration within the current flow; reduces need for complex browser/OS settings navigation.
- This needs to be carefully balanced against preventing spam. Solutions like reputation-based mechanisms or heuristics were deemed ethically and technically difficult, prone to manipulation, and unlikely to achieve the same high precision of user intent as a direct interaction with a dedicated element. An unpredictable heuristic would also lead to a poor developer and user experience.
This proposal does not introduce new risks or changes to accessibility, privacy, or security for clipboard operations. It maintains the fundamental permission and security requirements of the async Clipboard API (navigator.clipboard), including the need for a secure context and a user gesture to access clipboard contents.
Reference : Github discussion
Many thanks for valuable feedback and advice from: