Copying a file as a path versus as the file itself

There are two different things happening when you copy a file on a Mac, and they look identical until the moment you paste. Copy a file in Finder and paste it into another Finder window, and the file appears there. Copy the same file and paste it into a note or a chat box, and you might get the file, the file name, a preview, or nothing at all. The reason is that the file and the path to the file are two separate pieces of data, and the copy command can carry either one.

Knowing which is which saves a lot of confused pasting.

The file itself

When you select a file in Finder and press Command-C, the Mac records a reference to that file: where it lives on disk and enough information to hand the actual bytes to whatever asks for them. Paste into another Finder window and you copy the file there. Paste into an email and it becomes an attachment. Paste into a chat app that accepts uploads and the file goes up.

This is the version you want when the destination is going to store, send, or open the file. The receiving app takes the real thing, not a description of it.

The path as text

The path is different. It is a line of text that spells out where the file sits, something like /Users/you/Documents/report.pdf. It is not the file. It is an address for the file, written in a form a terminal, a script, or a configuration field can read.

macOS has a slightly hidden way to copy exactly this. In Finder, select the file, then open the right-click menu and hold down the Option key. The “Copy” line changes to “Copy [name] as Pathname”. Choose it, and the clipboard now holds the path as plain text. The keyboard version is Command-Option-C. Paste that into a terminal and you get the path typed out, ready to run a command against. Paste it into a text field and you get the same line of characters.

You want the path when the destination speaks in paths: a command line, a build script, a text box that expects a location rather than a file.

Why the same paste behaves differently

Here is the part that trips people up. When you copy a file the normal way, the Mac actually puts several representations on the clipboard at once: the file reference, the name, sometimes an icon or preview. Each app that receives a paste picks the representation it understands and ignores the rest.

A Finder window sees the file reference and copies the file. A rich note might see the name or a preview and drop that in. A plain text field sees only text, and since a file reference is not text, it may take the file name, or it may take nothing, because a normal Command-C did not put a usable path there. That is why pasting a copied file into a terminal often gives you nothing useful: the terminal wanted text, and the clipboard had a file, not a path.

So the choice is not really about the copy. It is about matching what you copied to what the destination can read. Copy the file when the target wants a file. Copy the path when the target wants text.

A quick way to decide

Ask what the destination is going to do with it.

If it will open, attach, upload, or store the file, you want the file itself. Use Command-C in Finder and paste normally.

If it will read the location as text, run a command on it, or record where it lives, you want the path. Use Command-Option-C, or hold Option in the right-click menu, and paste the pathname.

If you paste and get the wrong thing, you almost always guessed the destination’s preference wrong, not the copy. Undo, copy the other representation, and paste again.

Skipping the decision

The whole path-versus-file question exists because you commit to one representation at the moment you copy, before you know where the thing is going. If you copy the file and then decide you needed the path, you have to go back and copy again the other way.

Ledge removes that ordering problem. You drag a file up to the notch at the top of the screen and let it sit on a shelf. You have not chosen a representation yet. When you drag it off to somewhere, Ledge looks at where it is landing and hands over the form that fits. Drop it on a terminal and it types the path as text. Drop it on Finder and it moves the file itself. Drop it into a chat that takes uploads and it uploads the file. The same item on the shelf becomes a path in one place and a file in another, and you never open a menu or remember a modifier key.

That does not replace knowing the difference. Copy and paste is still the fastest route for a single, obvious move. But when you are gathering several files and are not yet sure where each one lands, holding them somewhere first and deciding on the way out is easier than guessing the representation up front.

The short version

Copying a file gives the destination a reference to the real file. Copying the path gives it a line of text that points at the file. Finder, chat apps, and email tend to want the file. Terminals, scripts, and location fields want the path. When a paste gives you the wrong result, you copied the representation the destination could not read, and the fix is to copy the other one.