A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Proposal: Modern, asynchronous Clipboard API


Asynchronous Clipboard API Proposal

The primary motivation for this proposal is to address the following issues present in the current synchronous Clipboard API:

  • For security reasons, user agents may need to sanitize images before putting them on the clipboard. This can be time-consuming for large images so it is not reasonable to do it on the main thread. Thus, the current synchronous-nature of the current API prevents images from being supported in some UAs.

  • Synchronous APIs restrict the options for getting user permission before performing an action. Some permission models (like the Permissions API) require an async API.

Similar proposals have been brought up in the past. In that discussion, it was suggest that we should get browsers to implement the current API before trying to modernize it. However, due to security concerns, Chrome cannot implement parts of the current spec (e.g., supporting images). Making the API asynchronous would allow Chrome to add support for these parts.


This looks exactly like it covers the requirements mentioned in the editing taskforce in the past by JS editor developers, so this really looks a great proposal. I also agree with your discussion about the security issues with the current setup (where is the security in letting users click arbitrary buttons to allow adding things to the clipboard the user hasn’t ever seen?) and your suggestions for improvements in that area look good.

However, each of those suggestions might either result in a slightly strange user experience and/or not be 100% security. For example, the “clipboard is being accessed” notification could end up looking scary to some users, while others ignore it completely. Neither one may completely understand what it means and what precautions they should take. But this is a difficult area, and there may not be any 100% perfect solution to dilemma. So I very much welcome this proposal and I hope it is merged into the Clipboard API in the near future.


I wonder how writeHtml would work – would it put one version in HTML and another in plaintext onto the clipboard? Will such a conversion from HTML to plaintext be the exact same in all browsers?