What the pasteboard holds when you copy a file

The Mac clipboard has a more formal name, the pasteboard, and it behaves in a way that explains a lot of everyday copy-and-paste confusion. When you copy a file, the pasteboard does not hold one thing. It holds several descriptions of the same file at once, and each app that pastes reaches in and takes the one it understands. Once you can picture what is actually sitting there, the times a paste comes out wrong stop being mysterious.

The pasteboard is not one slot

It is tempting to imagine the clipboard as a single box that holds whatever you last copied. In reality the pasteboard holds a set of representations, each tagged with a type that says what kind of data it is. A run of plain text, a chunk of styled text, an image, a file reference, and a URL are all different types. A single copy can drop more than one of them onto the pasteboard together.

macOS identifies these types with labels called uniform type identifiers. You do not have to read them, but the idea behind them matters: every piece of data on the pasteboard announces what it is, so a receiving app can look for the type it wants and ignore the rest.

What lands there when you copy a file

Copy a file in Finder and the pasteboard usually ends up holding a few things at once. There is a file reference, which points at the document on disk. There is often the file name as plain text. There may be an icon or a small preview image. For some sources there is also a promise: instead of the full data, the pasteboard holds an offer to produce it when a destination actually asks, which is how large files and drag operations avoid copying everything up front.

The important detail is what is usually not there: the full path as ready-to-use text. A normal copy records a reference to the file, not a typed-out location string. That gap is why pasting a copied file into a terminal so often produces nothing, and why macOS gives you a separate Copy as Pathname command, reached by holding Option in the Finder right-click menu, when you specifically want the path as text.

How apps choose what to read

When you paste, the receiving app does not take everything on the pasteboard. It asks for the types it can use, in the order it prefers, and takes the first match.

A Finder window asks for a file reference and copies the file. A plain text field asks for text and takes the file name, since that is the only text on offer. A rich document might ask for an image first, then styled text, then plain text, and use whichever it finds. A terminal asks for text and, finding only a file reference and a name, often gives you the name or nothing, because a file reference is not something it can type.

Nothing here is broken. Each app is reading the representation that suits it. The result surprises you only when the representation you had in mind is not the one the app reached for.

Why a paste sometimes comes out empty

An empty or wrong paste almost always means a mismatch between the types on the pasteboard and the types the destination wanted.

You copied a file, which put a file reference and a name on the pasteboard, then pasted into a field that only reads text and does not treat a name as useful. There was no path text to take, so nothing appeared. Or you copied an image file expecting the picture, but the pasteboard held the file reference rather than image data, so a document that wanted pixels had nothing to draw and showed the name instead.

The fix follows directly. Put the type the destination wants onto the pasteboard. For a path, use Copy as Pathname. For a picture, copy from an app that has the image open so the pasteboard carries image data. For a file, copy in Finder and paste somewhere that accepts files. You are not fighting the pasteboard, you are stocking it with the right representation.

Deciding the representation later

The awkward part of all this is timing. You choose what the pasteboard holds at the moment you copy, which is before you know where the thing is going. If you guess wrong, you go back and copy again in a different form. For a single paste that is quick. For a file that has to reach a terminal, a chat, and a folder in turn, it means copying it three different ways.

Ledge works around the timing rather than the pasteboard. You drag a file up to the notch and it rests on a shelf without committing to a representation. When you drag it off to a destination, Ledge produces the form that destination reads: the path as text for a terminal, an upload for a chat that takes files, the file itself for Finder. The same item on the shelf turns into a path in one place and a file in another, because the choice happens on the way out instead of at the moment you picked it up.

Copy and paste is still the right tool for a quick, single move where you know the destination. The shelf helps when one thing has several destinations, and copying it a new way for each one is the tedious part.

The short version

The pasteboard holds several typed representations of whatever you copied, not a single blob. Copying a file usually stores a file reference, a name, and sometimes an icon or a promise, but not the path as text. Each app pastes the type it understands. A wrong or empty paste means the type you wanted was not on the pasteboard, and the cure is to copy the representation the destination can actually read.