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

[Proposal] Raw Clipboard Access


Explainer: https://github.com/dway123/raw-clipboard-access/blob/master/explainer.md


Powerful web applications would like to exchange data with native applications via the OS clipboard (copy-paste). The existing Web Platform has a high-level API that supports the most popular standardized data types (text, image, rich text) across all platforms. However, this API does not scale to the long tail of specialized formats. In particular, non-web-standard formats like TIFF (a large image format), and proprietary formats like .docx (a document format), are not supported by the current Web Platform.

Raw Clipboard Access aims to provide a low-level API solution to this problem, by implementing copying and pasting of data with any arbitrary Clipboard type, without encoding and decoding.

This could be used by:

  • Online editors like Google Docs or Microsoft Office 365, copy/paste OpenOffice or Microsoft Word documents/spreadsheets/presentations (proprietary formats).
  • Figma or Photopea, to copy/paste PhotoShop/GIMP, GIFs, or RAW images, or already-supported formats with not-supported metadata (long tail of metadata).
  • Web Apps supporting “niche” types, like LaTeX, .ogg, etc (long tail of formats).

The existing Async Clipboard API’s re-encoding is still encouraged for use cases requiring only generic types, and easier to use as custom encoders/decoders would not be necessary, but raw clipboard access allows web applications with more specific or sophisticated clipboard support needs to meet those needs.


It is currently possible to set clipboard data to a base64 representation of a TIFF image or arbitrary data format

event.clipboardData.setData("text/plain", dataURL.split(",").pop())

The application can then convert the base64 representation of the file

$ xsel -o | base64 -w 0 -d > image.tiff

Alternatively the copied or pasted data can be converted to a File then written to a filesystem or piped to the application.

What are the use cases for a TIFF image in a Web application?


This API is proposed to improve interoperability between web and native applications. Native applications can essentially use any string to represent any format. Therefore, in the image/tiff example, a native application like Photoshop or GIMP may choose to paste an image to the clipboard as image/tiff, which is not included in the Clipboard API spec. Existing APIs like setData would then not be capable of interacting with image/tiff, so this can limit in this example image editing applications (like photopea.com or figma.com, who have asked for this sort of capability), as users would not be able to copy and paste this image format between these web and native applications.

If a native application were to only provide web-incompatible formats, this would mean that no web application could interoperate with it. Similarly, if a native application were to provide both web compatible and incompatible formats, it’s possible that the web application can only access a subset of information (ex. lossy-compressed web-compatible format and uncompressed web-incompatible format).

While an obvious solution for the specific case of image/tiff may be to simply add it to the Clipboard Spec, the long tail of formats is not feasible to add to the web platform, and proprietary formats are by definition impossible to add (without relinquishing intellectual property)


Just chiming in here in support. Working on the web version of SketchUp, we definitely run into user workflows that require copy and pasting 3D modeling geometry from one tab to another tab. This would certainly be useful when users are reviewing older revisions of files or working between two files.


Thank you for the support, Sketchmark! We’re certainly interested in creating a standardized way to allow clipboard interoperabilty with custom formats.

gked@microsoft also mentioned here that it may be helpful to move this to a WICG repository, so I’ll try to get that process started.


Sounds like there’s enough support for the use case to justify an incubation so moving the repo to WICG SGTM! :slight_smile:


The repo now lives in https://github.com/WICG/raw-clipboard-access

Happy incubating!!


This sounds very useful! We’d love to be able to support copy-paste between our native and web-based apps without resorting to base64 workarounds.