Copy to the Clipboard From the Command Line: pbcopy, pbpaste (and Linux, Windows)

On macOS, pbcopy reads its standard input and puts it on the clipboard, and pbpaste writes the clipboard to its standard output. That is the whole feature, and it composes with everything:

echo "hi" | pbcopy          # text -> clipboard
pbcopy < notes.txt          # file -> clipboard
pbpaste > out.txt           # clipboard -> file

Both ship with macOS, so there is nothing to install. The names come from the old NeXT/macOS pasteboard server (the pb is "pasteboard"). The point of having them is that anything that prints to a terminal can now feed the clipboard without you reaching for the mouse and triple-clicking. That is where they earn their keep.

Pipe command output straight to the clipboard

The everyday use is taking the output of a command you would otherwise select by hand and dropping it on the clipboard ready to paste into a chat, an editor, or a form:

# Your current SSH public key, ready to paste into GitHub:
pbcopy < ~/.ssh/id_ed25519.pub

# The current commit hash, to paste into a ticket:
git rev-parse HEAD | pbcopy

# Your machine's local IP:
ipconfig getifaddr en0 | pbcopy

# A directory listing:
ls -la | pbcopy

Because pbpaste writes to stdout, it works as the front of a pipe too. Paste the clipboard into a diff against a file, count its lines, or grep it:

pbpaste | diff - notes.txt   # compare clipboard to a file
pbpaste | wc -l              # how many lines did I just copy?
pbpaste | grep ERROR         # filter what's on the clipboard

A genuinely useful one I keep as a shell function: copy the output of the last command I ran. There is no built-in for "the previous command's output," so I re-run it into pbcopy. The te_ prefix here is just my own namespace so the helper does not collide with anything:

# In ~/.zshrc or ~/.bashrc
te_clip() { "$@" | tee /dev/tty | pbcopy; }
# Usage: te_clip git log --oneline -5
# Prints the output AND copies it.

tee /dev/tty is the trick: it shows you the output on screen and copies it at the same time, so you are not copying blind.

The options nobody reads: -pboard and -Prefer

Run man pbcopy and you find both commands take two flags that almost no one uses, but that occasionally matter. The full synopsis is pbcopy [-pboard {general | ruler | find | font}] and pbpaste [-pboard {general | ruler | find | font}] [-Prefer {txt | rtf | ps}].

-pboard picks which of macOS's named pasteboards you read or write. There are four: general (the normal Cmd+C / Cmd+V clipboard, and the default), find (the system find-pasteboard that Cmd+E populates so a search term carries between apps), ruler (copied paragraph formatting), and font (copied font attributes). In day-to-day use you only ever touch general, which is why you never pass the flag. The find board is the one with a real use: pbpaste -pboard find prints whatever you last copied as a search term.

-Prefer only exists on pbpaste, and it tells pbpaste which representation to pull when the pasteboard holds more than one. Its values are txt, rtf, and ps (PostScript), and the default behavior is plain text first. So pbpaste -Prefer rtf gives you the rich-text version of something you copied out of a word processor, instead of the flattened plain text. The older ss64 reference still lists this option as -Prefer {ascii | rtf | ps}; the current Apple man page uses txt, not ascii.

That txt/rtf/ps split mirrors how the two commands handle types in general. pbcopy writes your input as plain text unless it starts with an Encapsulated PostScript or RTF file header, in which case it stores it as that richer type. pbpaste reads back in the same priority order: plain text first, then EPS, then RTF. And per the man page, pbpaste removes the data as it reads it. In practice macOS leaves the clipboard intact for normal Cmd+V use, but the documented behavior is a one-shot read, so do not write a script that assumes you can pbpaste the same content twice in a row across a logout or app relaunch.

The same thing on Linux and Windows

pbcopy and pbpaste are macOS-only. There is no pbcopy on Linux or Windows, and this is the single most common follow-up question, so here is the equivalent for each platform. Pick your OS and the table below swaps in the right commands:

echo "hi" | pbcopy        # copy stdin
pbpaste > out.txt           # paste to a file
pbcopy < notes.txt          # copy a file

A few platform notes worth knowing:

• Linux X11 needs -selection clipboard. X11 has two separate clipboards: the primary selection (whatever you highlighted, pasted with middle-click) and the clipboard selection (what Ctrl+V uses). xclip defaults to primary, which surprises people, so pass -selection clipboard when you want the Ctrl+V one. Install with sudo apt install xclip or sudo apt install xsel.
• Wayland uses wl-clipboard. xclip/xsel are X11 tools and do not work under a pure Wayland session. Install wl-clipboard (sudo apt install wl-clipboard) for wl-copy and wl-paste, which need no selection flag.
• Windows clip only copies. The built-in clip command takes stdin and has no paste counterpart. PowerShell's Set-Clipboard and Get-Clipboard cover both directions and are the modern answer (note these live in Windows PowerShell 5.1; in cross-platform PowerShell 7 they are Windows-only).
• WSL can reach the Windows clipboard: pipe to clip.exe to copy out of Linux, and powershell.exe Get-Clipboard to read it back in.

The trailing-newline gotcha

This one bites everyone eventually. echo appends a newline, so echo "secret" | pbcopy puts secret\n on the clipboard, with an invisible trailing newline. Paste that into a password field, an API token box, or a .env value and it can silently break, because the trailing newline is now part of the string.

Use printf (which adds nothing you did not ask for) when the exact bytes matter:

echo   "token"  | pbcopy   # copies "token\n"  <- trailing newline
printf "token"  | pbcopy   # copies "token"    <- exactly that, no newline
echo -n "token" | pbcopy   # also no newline, but echo -n is not portable

printf "%s" "$value" is the safe, portable form. The same applies to every tool here: xclip, wl-copy, and clip all faithfully copy whatever bytes you pipe them, newline included, so the fix is to not send the newline in the first place. When copying a file with pbcopy < file, you get exactly the file's bytes, so a file ending in a newline carries it through too.

FAQ

See also

• Get a saved Wi-Fi password from the Mac Terminal: another built-in macOS one-liner, and security ... | pbcopy pairs nicely to grab the password straight to the clipboard.
• Base64-encode a file from the command line: base64 -i logo.png | pbcopy is the canonical "encode and copy a data URI" move.
• Using the open command on macOS to launch apps, files, and URLs: the other macOS terminal built-in worth keeping in muscle memory.