Copy and paste fails because the clipboard is not a single feature but a short-lived data pipeline: the app you copy from must format data, the OS must store it in memory, and the app you paste into must be allowed to read it. A break at any stage, such as a locked clipboard, missing permissions, or an incompatible format, silently drops the content.
That pipeline runs through roughly 1 to 10 megabytes of shared memory on most desktop systems. It survives app crashes but not reboots. And it fails in ways that rarely produce an error message, which is why "copy and paste not working" feels mysterious. The sections below trace the signal from keystroke to insertion, quantify where it breaks, and give you fixes with actual thresholds.
How the clipboard pipeline actually works
When you press Ctrl+C or Cmd+C, the source application does not hand its data to the OS. It registers a clipboard owner and publishes one or more formats, called flavors on macOS. A spreadsheet might publish plain text, rich text, and a private binary format at once. The OS stores only a reference plus a small allocation until something requests the payload.
Paste is a request. The target app asks the clipboard manager for the richest format it supports, and the OS asks the original owner to render it on demand. This lazy architecture saves memory and enables very large copies. It also means the source app must still be alive or have flushed its data. Close the source app before pasting, and on some platforms the payload evaporates.
This explains a key failure mode. The clipboard is a negotiation between two processes mediated by a third, the OS clipboard service. On Windows that is the Clipboard User Service, a per-session process. On macOS it is the pboard daemon. On Linux it is whatever X11 or Wayland compositor owns the selection buffer. If any one of the three is blocked, copy and paste quietly stops.
Plain language: copying is not copying. It is telling the OS "ask me for this later," and pasting is the OS actually asking.
Quantified context: memory, size, and time limits
Clipboard behavior is bounded by numbers most users never see. Windows supports clipboard data up to roughly 4 MB per allocation through the standard API, though applications using delayed rendering can exceed this by streaming. macOS has no hard published cap but slows noticeably past 100 to 200 MB. Linux X11 clipboards can hold gigabytes, but only while the owning process lives.
Persistence is equally bounded. The Windows clipboard survives sign-out and fast user switching but is cleared on reboot. Windows 10 and 11 add Clipboard History, which retains up to 25 items, the oldest evicted first. macOS keeps only the most recent item unless you use a third-party manager. Android's clipboard holds one item and clears it after a period that varies by version and vendor.
Timing matters too. A large copy, such as 500 MB of video frames, can take several seconds to render on first paste because rendering is deferred. If you paste again too quickly, some apps serve a stale or empty buffer. That is the classic "first paste is blank, second works" symptom.
Remote Desktop adds another hop. Clipboard redirection between a local and remote session is a separate channel with its own size limits, often 1 to 2 MB for file and text transfers. Copy a large block and it silently truncates or fails.
| Platform | Clipboard persistence | Default history | Typical size ceiling |
|---|---|---|---|
| Windows 10/11 | Cleared at reboot; kept across sign-out | 25 items with history on | ~4 MB per API allocation |
| macOS | Latest item; cleared at logout in some cases | 1 item | No hard cap; slow past ~200 MB |
| Linux X11 | While owner process runs | 1 item | Owner-bound, often GB |
| Android | 1 item, auto-cleared | 1 item | Small, tens of KB typical |
| iOS/iPadOS | 1 item, auto-cleared | 1 item (Universal Clipboard syncs briefly) | Small |
| Remote Desktop session | Session-bound | 1 item | ~1 to 2 MB redirection |
Edge cases that break copy and paste
Security software is the most common silent culprit. Clipboard access is a known data-exfiltration path, so endpoint protection and browser sandboxes increasingly restrict it. Chrome, Edge, and Safari gate clipboard reads behind a user gesture and a permission prompt. If a web app tries to read the clipboard without focus, the read is denied with no visible error. That is why "paste" inside a web form sometimes does nothing.
Remote and virtualized sessions are next. Citrix, VMware Horizon, and Microsoft Remote Desktop each enable clipboard redirection as a policy toggle. Administrators often disable it for security, and the user experiences it as a broken keyboard. Microsoft's own documentation frames clipboard redirection as a configurable feature, not a guarantee.
Then there is the privacy clipboard. Windows 11 and macOS both offer cross-device clipboard sync, which routes your copied text through cloud services. When sync is enabled but the network is offline, some apps appear to hang for 1 to 3 seconds before falling back. Disable sync and the delay often vanishes.
Red flag: copy works in one app but paste is blank everywhere. The owner process likely exited or was sandboxed. Red flag: paste works in text fields but not in a specific app. That app is blocking clipboard reads. Red flag: only large copies fail. You are hitting a size or redirection ceiling. Red flag: intermittent failures after a driver or OS update. A background service is being throttled. Red flag: failures only on battery or in a locked-down browser. Power or permission policy is intervening.
Misconceptions about copy and paste
The most persistent myth is that the clipboard holds your data inside the app. It does not. The data lives in memory owned by the source process until pasted, which is why quitting the app can lose it on some platforms.
Another myth is that clearing the clipboard frees meaningful memory. In practice a text clipboard uses kilobytes; a copied image or file list can use tens of megabytes. Clearing matters for privacy, not performance.
People also assume the clipboard is universal across apps. It is not. Sandboxed apps, browser tabs, and remote sessions each see a filtered view. A password manager that marks clipboard content as sensitive may set an expiry, often 30 to 90 seconds, after which paste returns nothing. That is a deliberate security feature, not a bug.
The counterintuitive detail: copy and paste can fail when the clipboard is too full of formats, not too empty. An app that publishes a dozen private flavors can confuse a simple target that requests one it cannot render, and some apps then paste nothing rather than fall back. The fix is often to paste as plain text, which requests the lowest common denominator.
Practical steps to restore copy and paste
Start with the sequence, because it isolates the broken stage. Copy from a plain text editor and paste into the same editor. If that works, the OS layer is fine and the problem lives in one of the two apps. If it fails, the clipboard service is the suspect.
On Windows, restart the clipboard service and clear history. Open Settings, System, Clipboard, and clear the history. Then sign out and back in. If failures persist, check whether a third-party clipboard manager is running; uninstall it temporarily. On macOS, quit the pboard process indirectly by logging out, or reboot. On Linux, restart the compositor.
For browser forms, click into the field first so the page has focus, then paste. If a site blocks paste, use the context menu rather than the keyboard shortcut; the menu path often carries the required gesture. For remote sessions, verify clipboard redirection is enabled in the client settings before blaming the keyboard.
Concrete thresholds to check: if only files over 4 MB fail, reduce the selection or transfer in parts. If paste timing is the issue, wait 2 seconds after a large copy. If a password manager is involved, paste within 30 seconds. If the failure started after a specific update, roll back that update and confirm.
A systematic order saves time. Test same-app, then cross-app, then cross-session, then cross-device. Each boundary you cross tells you which layer to fix.
Plain language: if copy and paste works in Notepad but not in your browser, the OS is fine and the browser is the problem.
| Symptom | Most likely layer | First action |
|---|---|---|
| Nothing pastes anywhere | OS clipboard service | Restart service or reboot |
| Paste works in some apps only | Target app permissions | Check app clipboard settings |
| Only large copies fail | Size or redirection limit | Split the transfer |
| Fails inside browser forms | Browser gesture/permission | Click field, use context menu |
| Fails in remote session | Redirection policy | Enable clipboard redirection |
| Stops after a few seconds | Sensitive-content expiry | Paste sooner or change setting |
Timeline: how a copy degrades over minutes
Clipboard failures often follow a predictable course. Knowing the time scale narrows the cause.
| Time after copy | What happens | What you observe |
|---|---|---|
| 0 seconds | Source publishes formats | Copy appears to succeed |
| 1 to 3 seconds | Large payload renders on demand | First paste may be slow or blank |
| 30 to 90 seconds | Sensitive-content expiry (if set) | Paste returns nothing |
| Minutes | Source app may be suspended or closed | Payload lost on some platforms |
| Sign-out | Session clipboard cleared on Windows | History-only recovery |
| Reboot | All clipboard data cleared | Nothing to paste |
| Cross-device sync lag | 1 to 10 seconds over network | Paste works late or not at all |
The takeaway: most "it worked a minute ago" reports fit the 30 to 90 second expiry window or a suspended source app. Check those two before reinstalling anything.
Limitations and what this cannot diagnose
This explanation covers the stable mechanics of clipboard architecture, which change slowly. It cannot diagnose your specific machine, because clipboard failures are frequently caused by installed software, organizational policy, or hardware input issues that are invisible from a general description. A keyboard that drops the Ctrl key, for example, produces identical symptoms to a broken clipboard.
Many apparent copy-paste failures are actually input failures. Test with the on-screen keyboard or the context menu before assuming the clipboard is at fault. Likewise, an app that appears to ignore paste may be receiving the data and rejecting it internally, which no clipboard setting will fix.
Where platform behavior is version-specific, treat the numbers here as typical ranges rather than guarantees. Vendor documentation and your organization's IT policy override anything general. When a fix requires changing a managed device, ask your administrator rather than working around a security control.