These are two of the defining features of the Macintosh, pioneered in the Xerox Palo Alto Research Center, and first offered to the general public in implementations by Larry Tesler (1945-2020), Jef Raskin (1943-2005), Bill Atkinson (1951-2025), Andy Hertzfeld and others at Apple.

What they do

Copy and paste is the older of the two, and less demanding to implement on slower hardware. Some of the contents of a document open in the source app are selected by the user, copied as discrete data to a clipboard intermediary, then pasted from that into a chosen location in a document opened in the receiver app, which could be the same document and app as the source.

Drag and drop is similar in many respects, but doesn’t require a clipboard. Some of the contents of a document open in the source app are selected by the user, then that selection is dragged to a chosen location in a document opened in the receiver app, which could be the same document and app as the source. Although in most cases, dropping inserts the dragged contents into a document, it can also insert them into a new file, for example in the Finder, where it becomes a clipping. The full interface for this wasn’t implemented in macOS until System 7.1.1/7.5 in 1993-94, almost a decade after the release of copy and paste.

Thus, copy and paste is primarily driven by the keyboard, and requires a clipboard intermediary, while drag and drop is direct manipulation using a mouse or trackpad without intermediary storage. They have common requirements.

Roles

The source app for both copy and drag is responsible for providing the selected contents in formats that can be accessed by other apps, in SwiftUI normally requiring that they are transferable. Each format is identified by its Uniform Type Indicator (UTI), so plain text might be provided as a string of UTF-8 text with the UTI of public.plain-text. Apps can use custom types, enabling better transfers within that app and others that support that type. AppKit’s approach is more traditional, and has standard Pasteboard types such as HTML and RTF.

The receiver app is responsible for obtaining the transferred contents in a format that it can access, again relying on its UTI or Pasteboard type. It then inserts the dropped or pasted contents into the chosen location within a document.

Copy and paste rely on what the user knows as the Clipboard to act as an intermediary, storing items that have been copied or cut, and providing them to receiver apps. Unfortunately Apple’s terminology waxes historical in referring to this Clipboard as a pasteboard server, which is shared by all running apps. AppKit apps interface with that server using NSPasteboard objects, but Apple has updated this for SwiftUI, which uses the same server under the Clipboard name.

How they work

To understand how these work together, I’ll take the example of a selected paragraph of styled text being copied from one app and pasted into another, features that are built into AppKit APIs, so they can be supported without the developer having to write a line of code for them.

The source app extracts plain and rich text versions of the selected string to be copied. Those are passed to the Clipboard (pasteboard server) as public.plain-text and public.rtf. From those the Clipboard might make available several presentations of the text, including

• public.utf8-plain-text encoded using UTF-8
• public.utf16-plain-text and public.utf16-external-plain-text encoded using UTF-16
• public.rtf encoded as a regular rich text file, complete with its font and styling information.

The user then switches to the receiver app with an open document, places the text cursor where they want the pasted text to go, and tells the app to paste what’s in the Clipboard there. The receiver app is then given the contents of the Clipboard in the type of its choice. Normally it will check which are available and read that as a string, a property list or a keyed archive, as appropriate. In this case the receiver can handle public.rtf, so it converts that to its internal representation of styled text, such as Attributed Text, and inserts it into the document’s data in the correct place.

Drag and drop is essentially similar, but without the Clipboard acting as its intermediary. You can see this in what cut and paste can’t do, create clipping files, the result of dropping transferred contents onto the Finder.

Transferable types

The main limitation of these services lies in the contents they can transfer. While different presentations of text are readily supported by both sources and receivers, PDF is one of the most widely used types that presents greater problems. These result from its underlying object-based format, where what appears to be a single block of text can consist of many objects, and a page can contain dozens or even hundreds. Unpacking a selection and presenting its contents in a transferable type isn’t offered in the PDF API, and few apps have risen to the challenge to provide their own, even though PDF is one of the listed Pasteboard types.

Future

Despite their ancient origins, both copy and paste, and drag and drop are flourishing in macOS, and are thoroughly supported in Apple’s most recent SwiftUI. Maybe they’ll even make it to the Mac’s fiftieth anniversary?

Further reading

NSPasteboard, the AppKit API for copy and paste
Clipboard, the SwiftUI API for copy and paste
Drag sources and drop targets, the AppKit API for drag and drop
Drag and drop, the SwiftUI API for drag and drop

Many of the features we take for granted in macOS today have long histories. For the last week I’ve been looking at drag and drop using the Finder’s clipping files. Thanks to comments by theam27 and joethewalrus, we know this goes back over thirty years to the heady days of System 7. Before that, transfer of information between apps relied on the even older mechanism of copy and paste, one of the original features of the Mac in 1984.

Since System 7 Pro (7.1.1) and more generally in System 7.5 in September 1994, we’ve been able to drag text and other contents from open documents and drop them into the Finder to save them in a clipping file. That in turn can be dropped into a document to insert its contents there. It became highly popular in subsequent years, and different types of clippings proliferated. theam27 has identified four general types, with a further ten for internet location clippings.

Clipping files have proved long-term survivors. In Classic Mac OS their data was stored as resources in the resource fork of a file with an empty data fork. That survived the transition to Mac OS X, where it eventually became the com.apple.ResourceFork extended attribute. Since around 2015 clippings have also been written to the file’s main data as a binary property list. Although those changes have orphaned some old clipping files, drag, drop and clippings are still flourishing in macOS Tahoe, where the Finder supports them as well as ever. There’s excellent support built into SwiftUI as well as traditional AppKit APIs. Those are of course also required for drag and drop more generally, in addition to the Finder’s clipping files.

Sequoia and Tahoe now offer at least two types of general clippings, in textClipping and pictClipping, and two internet location types webloc and mailloc. My first task was to discover their structure, which I reported here for both resource and data formats. Although Apple has long since retired its Carbon API support for accessing what were formerly resource forks, opening up property list data is relatively straightforward, and the goal of my new app Disclipper, coming tomorrow.

Although similar to copy and paste, and often implemented alongside them, drag and drop works separately. For content in a document to be draggable, the app has to declare it so, and provide its data in one or more transferable formats. Those are generally standard representations, such as UTF-8 text, although an app can also use its own formats. Each is labelled with its UTI, to enable the drop destination app to know how to handle them.

The user selects the content they wish to drag, then drags and drops it onto the Desktop or inside a location in a Finder window. The textClipping or pictClipping is then assembled from all the transferable formats, and built into a binary property list (as well as a com.apple.ResourceFork extended attribute). The key for each of those is the UTI of the transfer format, with the content as its value, normally as either a String for text, or Data.

For example, when you drag rich text from my editor DelightEd, the textClipping file generated by the Finder contains its data represented as:

• public.utf8-plain-text, the content as a UTF-8 string
• public.utf16-plain-text and public.utf16-external-plain-text, two variants of UTF-16 as Data
• com.apple.traditional-mac-plain-text, an old predecessor to UTF-8, probably Mac OS Roman, based on extended ASCII, but often truncated
• public.rtf, the content as rich text, thus containing font and other styling information.

The Finder then uses those to provide previews and, in the case of plain and rich text, its own reader window.

When you drag that textClipping into another document to paste its contents there, the receiver app is given the choice of transferable formats from the file, and should pick the richest of those to convert into its own content and insert into the document. You can check the fidelity of the process in an app with both drag and drop support by dragging a textClipping from it, then dropping that back into a new empty document, and comparing that with the original.

Other types of content use different clipping files, with further references to the history of macOS. Select an area from a PNG image in GraphicConverter and drag it out to turn it into a clipping with the extension .pictClipping and both its com.apple.ResourceFork xattr and data fork contain complete PICT and TIFF versions of the original image. In the data fork, the latter appear as the values for the UTI-Data key, under the UTI keys of com.apple.pict and public.tiff. PICT is a long-dead graphics file format for Classic Mac OS QuickDraw graphics, but lives on in clippings and apps like GraphicConverter.

The receiver app decides which format to accept from the clipping file. Create a textClipping from a webpage in Safari, and it should contain representations of that page as a WebArchive and rich text in an RTFD, but drop that into TextEdit and it will probably choose the latter. You don’t get the option to use the WebArchive format. Disclipper changes that by saving the WebArchive version for you to use when you wish.

One type of view that currently doesn’t appear to be supported by textClipping or pictClipping files is PDF, perhaps because its format isn’t really suitable for this approach to its content.

Apple’s SF Symbols app is another interesting example, as its textClippings use private Unicode code points that are rendered as custom icons only when using one of the SF fonts normally only installed by developers. Those can substitute for what might otherwise be displayed using vector graphics.

If you already use clipping files, you should find Disclipper handy; if you don’t use them yet, they could be a fine New Year’s resolution.

Further reading

Clippings 7 years ago
Current use
Formats