Copying is one of the most fundamental functions in almost every app. Copy some styled text from one window, and that text complete with its styling is stored in the Pasteboard (clipboard), ready for you to paste it in elsewhere. But there are times when it’s more useful to save what you’ve copied into a Clipping file; you can, for example, build a collection of these Clippings then paste them in sequence to construct a whole new document.
To create a Clipping file of some styled text, select it and drag that selection to the Finder location where you want to save it. It will then be turned into a file with the extension
.textClipping, which you can drag and drop into another document in another app. It should then carry its styling with it, as well as the text content.
Clipping files like this originated in the Classic Mac OS implementation of drag and drop, and they still have structural features which go right back to the 1990s. In Classic Mac OS and earlier versions of Mac OS X, they consisted entirely of data saved in the resource fork, which in macOS has become an extended attribute (xattr) of type
Extended attributes work fine locally on HFS+ and APFS file systems, but most are stripped when passed through iCloud, and some non-native file systems. Apple has therefore changed the format of Clipping files so that the copied data is also stored in the data fork, and should now remain usable when copied via iCloud.
Look at a Clipping file in Mojave, and you’ll see that it has substantial data in its xattrs and data fork. Clip 52-characters of text, for example, and there might be 1531 bytes of xattrs, and 1165 of data.
The xattrs included are likely to be:
com.apple.FinderInfo– 32 bytes of Finder information,
com.apple.lastuseddate#PS– 16 bytes revealing when the Clipping was last used,
com.apple.ResourceFork– in this case 1483 bytes of binary data in traditional resource fork format.
com.apple.ResourceFork, you’ll find the Rich Text format content of the Clipping, such as
\f0\fs26 \cf2 Quadrupedante putrem sonitu quatit ungula campum.}
(In case you’re wondering, the text is a line in Latin from Virgil’s ‘Aeneid’ Book IV.)
Note that this example uses the Mojave dual-mode RTF trick of an expanded colour table for text so that it shows properly in both Light and Dark Modes, where that is used in the original app (here, DelightEd). Unfortunately this also means that the currently buggy QuickLook thumbnail and preview don’t show any dual-mode text content properly when in Dark Mode. However, when in Light Mode you should be able to preview the Clipping’s contents in the Finder.
In more recent versions of macOS, the data fork consists of an XML Property List in binary format (BPL) containing a standard dictionary of key-value pairs. The two top-level keys are:
- OSType-Data, which in turn contains style and ustl key-value pairs;
- UTI-Data, which contains several different representations of the data listed by UTI keys.
For a styled text Clipping, the UTI-Data representations include:
public.rtf, which is RTF text exactly as in the resource fork
public.utf8-plain-text, which is modern UTF8 plain text.
When the Clipping is pasted into its destination, the most suitable of those formats is used for that paste operation.
Should you wish to access Clippings yourself, perhaps from a Linux or Windows system, you can read in the XML Property List and choose the most appropriate representation of the copied data from there.
Other types of content use different Clipping files, which become more complicated. For example, a JPEG image clipping has the filename extension
.pictClipping, and both its
com.apple.ResourceFork xattr and data fork contain complete PICT and TIFF format 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
public.tiff. PICT is a long-dead graphics file format for Classic Mac OS QuickDraw graphics, but lives on in Clippings.