#Start with a 60-second test
To fix the clipboard, restart the process that owns it: run killall pboard in Terminal on a Mac, or restart Windows Explorer and the Clipboard User Service on Windows. If that changes nothing, the clipboard is not broken and the app you copied from or pasted into is the real problem. That second half is where most troubleshooting goes wrong, so it is worth proving which case you are in before you touch anything.
Open two plain text windows. On a Mac, TextEdit and Terminal will do. On Windows, two Notepad windows. Type a word in the first, copy it, click into the second, paste. Three things can happen, and each one sends you somewhere different.
| What happens | What it means | Where to go |
|---|---|---|
| The word pastes fine | The system clipboard is healthy | Skip to the per-app section |
| Nothing pastes, anywhere | The clipboard process is stuck | Restart it, per your OS below |
| Old text pastes instead | The copy never landed | The source app blocked the copy |
Use plain text editors on purpose. Rich text apps, browsers and Electron apps each add their own layer, and any of them can fake a clipboard failure.
On a Mac there is a faster version of the same test that skips the apps entirely. Terminal talks to the pasteboard directly, so if these two lines work, the operating system is not your problem:
# does the pasteboard itself work?
echo hello | pbcopy
pbpaste
If pbpaste prints hello, stop looking for a system fix. I run this before anything else, because it has saved me from restarting a Mac at least a dozen times when the real culprit was a browser tab.
#Fix the clipboard on a Mac
macOS calls the clipboard the pasteboard, and a small background daemon named pboard holds it. It is a user-level process, launchd supervises it, and killing it is safe. You lose whatever you last copied and nothing else.
# restart the pasteboard daemon; launchd brings it back
killall pboard
No sudo, no restart, no confirmation dialog. Copy something afterwards and the pasteboard is rebuilt from scratch. If you have ever wondered why the reboot fix works, this is the part of the reboot that was actually doing the work.
If that does not help, work through the causes in the order they occur, most common first.
- A clipboard manager is holding the pasteboard. Any app that watches for copies polls the pasteboard constantly, and a stuck one can starve everything else. Quit it and retest. If paste starts working, you found it.
- The source app quit before you pasted. macOS lets an app put a promise on the pasteboard instead of the data: a declaration that it can supply a PDF or an image if asked. If that app quits before you paste, nobody can fulfil the promise and the paste comes back empty. Copy again with the source app still running.
- Universal Clipboard is not connected. Copying on an iPhone and pasting on the Mac needs both devices on the same Apple Account, Bluetooth and Wi-Fi on, Handoff enabled under System Settings, General, AirDrop & Handoff, and the two devices near each other. The copied content is also only offered for a short time, so a copy from an hour ago will not be there.
- A virtual machine or remote session is in the way. Parallels, VMware, UTM, Screen Sharing and every remote desktop client sync the clipboard through their own guest agent. When paste stops working between host and guest, that agent is what failed, not macOS. Restart the guest tools rather than the Mac.
- The Mac needs a fresh login session. Logging out and back in restarts every per-user daemon including the pasteboard, and it is faster than a full restart.
One more macOS detail worth knowing: Finder can show you the current clipboard contents. Click the desktop, open the Edit menu, choose Show Clipboard. It is a plain window with one item in it, and it is the quickest way to confirm whether a copy landed at all. If you want the full picture of how copying behaves across macOS, including paste and match style, I wrote that up in how to copy on a Mac.
#Fix the clipboard on Windows 11 and 10
Windows splits the job in two. The clipboard itself belongs to the window manager, while the history panel you get with Windows key plus V is run by a separate per-user service. They fail independently, which is why paste can work while history stays empty, and why one fix does not cover both.
Work down this list and retest after each step.
- Restart Windows Explorer. Open Task Manager, find Windows Explorer under Processes, right-click, Restart. The taskbar blinks. This clears most stuck-paste cases on its own.
- Clear the current contents. A single oversized or malformed item can jam everything behind it. Settings, System, Clipboard, then Clear clipboard data. The command line version does the same thing.
- Restart the Clipboard User Service. In Services it appears as Clipboard User Service with a random suffix, because it runs one instance per signed-in user. Signing out and back in is the reliable way to restart it, since the Stop button is usually greyed out.
- Check history is switched on. Settings, System, Clipboard, Clipboard history. On a managed work machine an administrator policy can lock this off, and no amount of local troubleshooting will turn it back on.
- Repair system files. If paste fails in every app after all of the above, run these from an elevated prompt and reboot afterwards.
:: overwrite the clipboard with nothing cmd /c "echo off | clip" :: repair system files, then reboot sfc /scannow DISM /Online /Cleanup-Image /RestoreHealth
Two Windows-specific traps catch people constantly. The first is Remote Desktop: clipboard sharing there runs through rdpclip.exe on the remote machine, and it dies quietly. End that task in the remote session, start it again from the Run box, and copy and paste come back without dropping the session. The second is Excel throwing "Cannot empty the Clipboard", which almost always means another program has hooked the clipboard chain. Close clipboard managers, remote sessions and screen recorders one at a time until Excel stops complaining.
#When one app is the problem, not the clipboard
If the two-editor test passed, the clipboard is fine and you are looking for an app that is choosing not to cooperate. Some of these are bugs. Several are deliberate, which is why they never get fixed.
- Password managers wipe the clipboard on a timer. Copy a password, take too long, and paste gives you nothing. That is the feature working. The timeout is usually configurable in the app's security settings.
- Websites can cancel copy and paste. Banking forms, exam platforms and some enterprise web apps intercept the event in JavaScript. Right-click and choose Paste from the context menu first, since some pages only block the keyboard shortcut.
- Browser paste buttons need a permission. Web apps that read the clipboard themselves, rather than receiving a keystroke, use an API that needs the site's Clipboard permission. Deny it once and that site's paste buttons fail silently forever while the normal shortcut still works. Check the padlock menu in the address bar.
- The formats do not match. You copied styled text and the destination only takes plain, or the reverse, and the paste arrives mangled or empty. Shift plus the usual paste shortcut asks for plain text in most apps.
- The item is too large. A whole spreadsheet or a very large image can take a noticeable moment to transfer, and some apps time out instead of waiting. Paste into a plain editor first to see whether the data is really there.
There is a related failure that looks identical from the outside: you copied the right thing, then copied something else before pasting, and the first item is simply gone. The clipboard holds one item. Nothing warns you when you overwrite it. This is the single most common "the clipboard is broken" report I hear, and the fix is not a fix at all, it is a history.
#Clipboard history is a separate system
People searching for how to fix clipboard problems are often not describing a fault. They pressed the history shortcut, saw an empty panel, and assumed something broke. Usually nothing did.
On Windows, history keeps around 25 items and empties every time you sign out or restart, unless you pin the entries you want to survive. An empty Windows key plus V panel the morning after a reboot is the designed behaviour. Syncing that history to another PC needs a Microsoft account and the sync toggle switched on separately.
On macOS the situation is blunter. There is no clipboard history. The Mac holds exactly one item, Finder's Show Clipboard window displays that one item, and no combination of settings will produce a list of previous copies. Every Mac history you have seen came from a third-party app.
That gap is why the Mac clipboard manager category is so crowded. Maccy is the free, open source, keyboard-driven option and is where I would send anyone who just wants a list of recent copies with no other opinions attached. Paste sits at the other end: a visual, subscription-priced app built around a full-screen board of clips. The wider comparison, including what macOS does and does not store on its own, is in my write-up on the Mac clipboard.
Adding a manager also changes the diagnosis for everything above. When you run one, it is now a suspect in every clipboard failure, because it is the app touching the pasteboard most often. Quitting it should be the first thing you try, not the last.
#Stop it happening again
Clipboard faults cluster. Once you have hit one, you tend to hit the same one repeatedly, because the cause is still installed. A few habits cut the repeat rate down.
- Run one clipboard manager, not three. Two apps polling the same pasteboard is the classic recipe for a stuck copy, and it is easy to end up with a standalone manager plus a launcher plus a notes app all watching.
- Paste as plain text by default. Most of the "paste did nothing" cases I have chased were formatting mismatches, not data loss.
- Learn your remote agent. If you spend the day in a VM or an RDP session, know the name of the process that syncs the clipboard. Restarting rdpclip.exe or the guest tools takes seconds; rebooting a remote server does not.
- Keep the restart command handy. killall pboard on a Mac, or Task Manager and Restart on Explorer for Windows. Both are cheap enough to try before you investigate anything.
- Give the clipboard somewhere to be seen. Half of these problems are invisibility rather than failure. When you can see what you copied, you stop guessing whether the copy worked, which is the whole reason history apps exist. Where that lives is a matter of taste: a menu bar icon, a window, or the notch on a MacBook.
If your menu bar is already too crowded to add anything, that is a solvable problem in its own right, and I covered the options in hiding menu bar icons on a Mac.
#Frequently asked questions
How do you reset your clipboard?
On a Mac, open Terminal and run killall pboard. That kills the pasteboard daemon, and launchd starts a fresh one the next time anything copies. On Windows, open Settings, go to System then Clipboard and choose Clear clipboard data, or run cmd /c "echo off | clip" to overwrite the current contents with nothing. Neither action needs a restart and neither one deletes files.
How do I reactivate my clipboard?
The clipboard itself cannot be switched off, so there is nothing to reactivate. What can be switched off is clipboard history on Windows: open Settings, go to System then Clipboard, and turn Clipboard history on, then press Windows key plus V. On a managed work PC an administrator policy can disable that toggle entirely. macOS has no history feature at all, so nothing there can be turned on or off either.
Why is my clipboard not showing copied items?
On Windows, clipboard history holds about 25 items and empties every time you sign out or restart unless you pin the entries you want to keep, so an empty Windows key plus V panel after a reboot is normal. On macOS there is no history to show: the Mac keeps exactly one item at a time, and Finder's Edit menu Show Clipboard command displays only that one. Seeing a history on a Mac requires a clipboard manager.
Why can't I copy anything to the clipboard?
Usually because a single app is blocking it rather than the system failing. Password managers wipe the clipboard a few seconds after a copy on purpose. Some banking and exam sites cancel the copy event in JavaScript. Remote desktop sessions and virtual machines only share the clipboard when their own agent is running. Test with two plain text editors first: if copy works there, the clipboard is fine and the app is the problem.
