Clipboard Inspector

Working with the clipboard in web browsers is subject to many inconsistencies. This tool helps you explore the content of the clipboard when you paste something on a web page.

Run it online: https://evercoder.github.io/clipboard-inspector/

Reading from the clipboard

A paste event contains the clipboardData property, which has the following properties of interest:

• types is an array of MIME types available in the clipboard;
• items is a list of DataTransferItem objects (DataTransferItemList);
• files is a list of File objects available in the clipboard.

Additionally, clipboardData contains the getData(type) method to fetch a string representation of the data for a specific format.

In our context DataTransferItem.getAsString() seems to be useless, as textual data can be read synchronously through other methods.

Specification

W3C Clipboard API and Events, Editor's Draft.

Scenarios

Exploring the behavior of Chrome, Firefox, and Safari in various situations.

Pasting plain text content

All browsers have a text/plain type and the content is easily accessible.

Pasting HTML content

All browsers provide the HTML content in the text/html type, and the stripped-down content in text/plain type (similar to .innerHMTL vs .textContent).

Pasting RTF content

For example, from Notes or Pages.

Firefox has text/plain and text/rtf types. No text/html. Chrome contains, in addition to text/plain and text/rtf, a text/html representation of the content. Safari only contains the stripped down text/plain type.

Pasting Google Docs content

All browsers will contain text/plain and text/html versions of the content. Images sources are URLs. The originating browser (where the Copy operation took place) retains custom, application-specific MIME types. In addition, Safari can report which browser originated the copy through a specific MIME type (but empty content).

Pasting an image file from Finder

All three browsers report the file name in text/plain type.

Chrome exposes a File of image/png type (regardless of the image format on the disk) containing the image data, with the name set to image.png.

Firefox exposes a File of image/png type containing... the generic MacOS image thumbnail, with the name set to image.png. Issue here.

Safari exposes a file of image/* (depending on the image format) containing, presumably, the image data, but which cannot be transformed into an object URL, with the name set to the file name. (Error in console: Failed to load resource: The operation couldn’t be completed. (WebKitBlobResource error 4.))

Pasting multiple image files from Finder

All three browsers report the concatenated file names in text/plain type.

Firefox has no other usable data. Issue here.

Chrome offers a File with the content of the last image in the selection, under the name image.png of type image/png.

Safari has individual entries in files for each image, but with the same problem in using the image data as the single-image scenario.

Pasting image data from a system app

For example, copying part of an image in Preview.

Firefox and Chrome report a single entry in the types array: Files. The image data is available in files under the name image.png of type image/png.

Safari exposes the public.tiff and image/tiff data types (no actual data for them, though), and no items, nor files arrays (issue here). Data types may be useful in isolating Safari and falling back to pasting into a contenteditable div and subsequently retrieving the image data from there.

Pasting proprietary data from a system app

The W3C spec lists a series of MIME types that the browser must support (among which text/plain, text/html, et cetera). Support for custom, application-specific MIME types is not mandated by the spec, but is indeed a Very Nice Thing To Have.

Firefox (issue here) and Chrome (issue here) filter out custom MIME types that the application might have put into the clipboard. Safari, on the other hand, provides much more liberal access to the clipboard's content, and is at the moment of writing the only browser in which a web application could potentially handle interesting file formats from the clipboard, like the ones from Sketch or Adobe Products.

Some browser milestones

Note: It turns out it's pretty hard to test this across browsers, as Browserstack, Sauce Labs, Browserling et al only support basic clipboard functionality.

Firefox

• Firefox 50 made clipboardData.items available
• Firefox 52 changed clipboardData.types to a simple array; that means it's best to always cast types to an array, just to be sure.

Running the project locally

The project requires Node and NPM/Yarn to run locally. It's built with React (piped through Babel / Webpack) — a bit more cumbersome to set up but makes it easy to prototype quickly.

After cloning the repo, run yarn (or npm install) in the project folder to install all dependencies.

To start a local server:

yarn start (or npm start)

This will make the project available on http://localhost:1234.

To build the project:

yarn build (or npm build)

To deploy the project:

yarn deploy

This will build the project and push the dist/ folder on the gh-pages Git branch. GitHub Pages is set up to work with this branch.

Additional resources

• Clipboard test is a similar tool built by Evan Wallace (of Figma) in May 2015.