You copy a paragraph from a webpage. You paste it into a document. The text arrives with the wrong font, wrong size, wrong color — the original website formatting came along for the ride.
Everyone has experienced this. Most people just use "Paste and Match Style" and move on. But the underlying mechanism is interesting, and understanding it explains a lot of clipboard behavior that otherwise seems arbitrary.
The short version: when you press ⌘C, macOS doesn't store a single piece of data. It stores the same content in multiple formats simultaneously. The app you paste into decides which format to use. That decision is why pasting sometimes brings formatting and sometimes doesn't.
The clipboard stores multiple representations
This is the key concept. A single copy operation places multiple representations of the same data onto NSPasteboard. Not one format — many, all at the same time.
Copy a sentence from Safari, and the clipboard might contain:
public.utf8-plain-text— the raw text, no formattingpublic.rtf— Rich Text Format with fonts, sizes, colorspublic.html— the original HTML from the webpagecom.apple.webarchive— a complete archive of the HTML with resourcespublic.utf16-plain-text— same text in UTF-16 encoding
All of these exist on the clipboard simultaneously. The app doing the copying decides which representations to provide. Safari provides all the above because it can. A plain-text editor like Terminal only provides plain text because that's all it has.
The clipboard is not a slot that holds one thing. It's a dictionary that maps data types to data. One copy operation can write a dozen representations. The receiving app picks the one it wants.
This design is clever. It means the source app doesn't need to know what the destination app supports. It just provides everything it can, and the receiver picks what's appropriate.
Common clipboard types (UTIs)
macOS uses Uniform Type Identifiers (UTIs) to label clipboard data. These are hierarchical strings — a type system for data formats. Here are the ones you'll encounter most:
UTIs are hierarchical. public.utf8-plain-text conforms to public.plain-text, which conforms to public.text, which conforms to public.data. Apps can ask for data at any level of specificity.
Some apps also place custom types on the clipboard. When you copy cells in Excel, it puts its own com.microsoft.excel.xlsx representation alongside plain text and HTML. This is how paste fidelity works between instances of the same app.
How apps choose which format to paste
When you press ⌘V, the receiving app doesn't get "the clipboard contents." It queries the clipboard for available types, then requests the richest format it can handle.
The algorithm looks roughly like this:
- App asks
NSPasteboardfor available types - App checks its own priority list of supported types
- App requests data for the highest-priority match
- Pasteboard returns data in that format
A rich text editor (Pages, Word, Notes) will prefer public.rtf or public.html — it wants formatting. A plain text editor (Terminal, VS Code's integrated terminal) will grab public.utf8-plain-text — it ignores formatting entirely. A code editor typically prefers plain text but might accept rich text for syntax-colored pastes.
This is why the same copy operation produces different paste results in different apps:
- Copy formatted text from Chrome
- Paste into Pages → formatted (Pages grabbed the RTF)
- Paste into Terminal → plain text (Terminal only accepts plain text)
- Paste into Notes → formatted (Notes grabbed the HTML)
- Paste into VS Code → plain text (VS Code prefers plain text for code editing)
NSPasteboard type resolution
- Source app calls
setData(_:forType:)for each representation - Clipboard stores all representations keyed by UTI
- Receiving app calls
typesto see what's available - Receiving app calls
data(forType:)for its preferred type - If preferred type isn't available, falls back to next preference
Why "Paste and Match Style" exists
Now the formatting problem makes sense. When you paste formatted text into a document, the app grabs the rich representation (RTF/HTML) because it can. The formatting from the source arrives intact — wrong font, wrong size, wrong everything.
Paste and Match Style (⌘⇧⌥V in most apps, or ⌘⇧V in some) tells the receiving app to ignore rich representations and use only the plain text version. Then it applies the destination document's formatting to the pasted text.
It's not "removing" formatting. It's choosing a different clipboard representation — the plain text one — and then applying local styles.
Not every app supports the same keyboard shortcut for Paste and Match Style. Some use ⌘⇧⌥V, some use ⌘⇧V, and some bury it in the Edit menu. You can remap it system-wide via System Settings → Keyboard → Keyboard Shortcuts → App Shortcuts. Add a shortcut for "Paste and Match Style" in All Applications.
There's an interesting edge case here. Some apps implement ⌘V to always match style — they deliberately request only plain text even when rich representations are available. This is a design choice by the app developer, not a clipboard behavior.
What clipboard managers capture
Clipboard managers face an interesting challenge with multiple representations. When a copy event occurs, they need to decide what to store. Saving every representation of every copy would consume storage quickly — especially with images and web archives involved.
Most clipboard managers make pragmatic choices:
- Text items: Store the plain text representation (and sometimes RTF for rich text fidelity)
- Images: Store the image data (PNG or TIFF)
- Files: Store the file URL reference
- Discard: Web archives, custom app formats, and redundant encodings
When you paste from a clipboard manager's history, you're typically getting the plain text or the image — not the full multi-representation original. This is usually fine. The rare case where it matters is when you need to paste rich text from history with its formatting intact.
QuietClip stores text, images, and files with full fidelity. When you paste a text item from history, you get the plain text. When you paste an image from history, you get the original image data. Files paste as file references.
QuietClip Pro stores images and files alongside text in your history — not just plain text representations. This means screenshots, copied images, and file references are all searchable and re-pasteable from your clipboard history.
The format system explains another common question: "Why did my clipboard manager only save the text when I copied an image with a caption?" Because the manager chose to store one representation, and it picked text. Good managers store the primary content type — if you copied an image, it stores the image. If you copied text that happened to have an image nearby, it stores the text.
Understanding clipboard formats demystifies most of the "weird" behavior people encounter. Formatting arriving unexpectedly, formatting disappearing, images not pasting from history — it all comes back to multiple representations and which one gets picked.
Your clipboard history, preserved faithfully.
QuietClip stores text, images, and files exactly as copied. Every format, searchable and ready to paste. Free for 25 text items, $8.99 once for Pro with images, files, and 1,000 items.