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.
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.