Who else can read the clipboard after you copy a password

An operator mints a database password, hits Copy, and switches to a terminal. For the next half minute that string lives in three places at once: the generator field, the system clipboard, and every input that might receive the next paste. People usually verify the first half of the story — whether generation uploaded anything. Another article covers how to confirm in Network that plaintext never left the browser. The second half is skipped: after Copy succeeds, who else can still read that buffer.

This is not a tour of how to mint a strong or readable password, and it is not a product feature list for the Copy button. The question is one sentence: once a password is on the clipboard, which kinds of programs can still read it. MyPassGen’s Copy control calls navigator.clipboard.writeText and writes the string into the system clipboard. There is no in-site vault. Close the tab and the server does not keep that password. The clipboard is still the operating system’s shared area. The page can close. The buffer stays. The paths below come from the spec, from OS settings, and from steps you can run yourself.

Once copied, the secret has left the page

The field on a generator page belongs to the current tab. The clipboard belongs to no tab. MDN describes the Clipboard API as asynchronous read and write of the system clipboard: after a write succeeds, Notepad, a terminal, a chat window, and a remote-desktop session can each read under their own rules. HTTPS only covers the hop from that page to a server. It does not cover this buffer on your machine.

The older document.execCommand('copy') call is marked deprecated, and implementations disagree. New pages should use navigator.clipboard.writeText. A write usually does not ask “allow this page to read.” Chromium treats clipboard-write as a permission it can grant automatically. Firefox and Safari still want a recent user gesture — a click or a keypress, the spec’s transient activation. Clicking Copy is that gesture. A script that writes in the background often fails in Safari. That is why some pages refuse to copy until you click. It is not the site being difficult.

MyPassGen uses the same writeText path for a generated password, a one-time link, and a cleaned result. Every tool opens without an account. A successful copy only proves the string reached the system clipboard. It does not prove who will read it a few seconds later, and it does not prove the string will stay out of Win+V history. Treating “Copied” as the end of the story is how the later paths get skipped.

Web reads: permission and paste events

A page that wants to read the clipboard on its own uses navigator.clipboard.readText() or read(). The spec wants a secure context — HTTPS or localhost — and it wants the read to happen just after the user has done something on the page. Browsers do not implement that the same way. That difference is something you can try right now.

Chromium: the clipboard-read permission

Chrome, Edge, and other Chromium browsers ask for the Permissions API’s clipboard-read when the document has focus but the read does not fully match the spec. If you click Allow, the grant sticks: scripts from the same origin can read again without another prompt. Site settings list Clipboard, and you can revoke it. An iframe embedded in someone else’s page also has to pass the Permissions-Policy tokens clipboard-read and clipboard-write. If the parent never allowed them, the child call fails. You can confirm this in DevTools under Application → Permissions. It is not a slogan.

Firefox and Safari: a short-lived Paste menu

Firefox and Safari do not plan to ship that persistent permission. When a read is off-spec but transient activation is still present, they show a brief context menu with a single Paste item that becomes clickable after about one second. Same-origin clipboard content can sometimes skip that step. Cross-origin content usually cannot. If you never click that item, the script does not get the text. That is not the Chromium model of “allow once, read later.”

When you paste, the page can always read

Ctrl+V / Cmd+V, or Paste on an input, fires a paste event. The handler can take the text from clipboardData. You handed it to the current page. That is not a background steal. The risk is focus: a chat box, a ticket reply, or the wrong browser settings page, and your fingers are faster than your eyes. The clipboard does not ask “are you about to paste a password?”

Phones add another layer. Since iOS 14, an app that reads the clipboard in the background flashes a banner at the top. Since iOS 16, an app that reads UIPasteboard directly — instead of the system paste menu, a keyboard shortcut, or UIPasteControl — is asked whether to allow the paste. A banner or a prompt proves someone read. It does not prove no one has ever read. A quiet moment only means this attempt did not fire, or you already allowed it.

System history and cloud sync

Web permission only covers scripts in the current tab. The operating system keeps its own history, and it may sync that history to other devices. Neither path goes through a clipboard-read prompt.

On Windows 10 and 11, with clipboard history on, Win+V shows recent copies. Microsoft’s own note is specific: the list holds at most 25 items. Unpinned entries clear on restart. Pinned ones stay. Settings can also turn on sync across devices: text follows any PC signed in with the same Microsoft account. Once a password is in that history, anyone sitting at this machine — and anyone on a synced target — can read the plaintext in the panel. Pin is the worst case. Restart does not wipe a pinned item. “Clear all” also leaves pins.

Apple’s Universal Clipboard rides Handoff. Devices must be nearby, signed in to the same Apple Account, with Bluetooth and Wi-Fi on, and Handoff enabled (it is on by default). Copy on one device and a nearby device can paste. The content stays only a short time, or until either side copies something new. Apple’s platform security guide is blunter: apps can reach clipboard data before the user has pasted; with Universal Clipboard on, that reach extends to other devices on the same iCloud account. The transport uses the same Handoff channel — BLE 4.2 pairing, a 256-bit AES key, advertisements in AES-256-GCM. That stops a stranger on the radio. It does not mean “the iPhone next to you, already signed in, cannot read this.”

Password managers treat the clipboard as a short exposure window. 1Password clears a copied secret after about 90 seconds by default; you can turn that off in Security settings. Bitwarden offers Clear Clipboard on desktop, mobile, and the browser extension, from about 10 seconds to 5 minutes, or never. A generator page in the browser usually does not do this for you. MyPassGen does not start a countdown after Copy. Overwrite means you copy something else, or you clear the system panel yourself.

Remote desktop, extensions, and mis-paste

Remote desktop, VNC, and many meeting apps redirect the clipboard both ways by default. Copy inside the remote session and the local machine can paste. Copy locally and the far side can paste. The password then sits in both buffers. During a screen share, characters you just pasted into a terminal can also land in a meeting recording or a screenshot. That layer is not “did the page upload.” The Network panel will not show it.

A browser extension that asked for clipboardRead / clipboardWrite — or Chromium’s matching host permissions — can read and write outside the page-script permission model. The store listing shows those permissions. An installed “clipboard booster” or “paste across devices” add-on is another sync channel. Do not stop at “did the generator upload.” Look at the extension list too.

The most common leak, and the easiest to reproduce, is still a mis-paste: focus sits in Slack, a mail body, or a ticket reply, and a finger hits paste. Chat history, mail archives, and ticket systems keep plaintext far longer than a 90-second clipboard clear. When a remote colleague needs the secret once, use a one-time link: the key sits after # in the URL, and the read page does not require a login. Do not copy the same plaintext into the clipboard and then into a group chat.

Five leak paths, side by side

The same fresh test password splits into at least five paths. The difference is not an algorithm name. It is who can read, and whether you can see that read happen.

A generator that draws a random string with Web Crypto, and that never puts the password in a Network body, only closes the upload path. The other four rows stay open. When a manager can autofill, you never need the clipboard. When you must type or must copy, shrink the window to “paste, then overwrite at once.”

Check it on the spot

These steps do not depend on a brand promise. Use a password you will not put on a real account — for example the generator’s default 16-character random string. Do not rehearse with a live master password.

1. Open the generator, mint a test password, and copy it. Do not use it to sign in. Open DevTools Network, enable Preserve log, and confirm that after Copy the request bodies and analytics events do not contain that string. How to check uploads is in How to verify that browser encryption did not upload plaintext.
2. Open Notepad or any text field and paste once. Confirm the clipboard holds that string. Copy a single character x, then paste again: you should see x. That is overwrite working.
3. On Windows with clipboard history on, press Win+V. The history should show the test password. If you already overwrote, the newest item should be x, and the password may still sit lower in the list. Do not pin. Use Clear all, or keep copying junk text, until the password is gone from the list.
4. In a blank tab’s console, run navigator.clipboard.readText().then(console.log, console.error). Chromium should prompt for read permission or fail. Firefox or Safari should show a Paste item or refuse. Do not click Allow “to make debugging easier.” Allow leaves a persistent read grant for that origin.
5. If a second device is signed in to the same Apple Account or Microsoft account with sync on, paste there. If the test password appears, cloud sync or Universal Clipboard already moved the plaintext. Turn sync or Handoff off, or wait for the timeout, and try again.
6. Read the permission list on installed extensions for clipboard read or write. If a remote-desktop session is open, paste once in Notepad on the far side to see whether redirection is on.

MyPassGen’s password generator is built on that boundary. Random mode is 6–128 characters, default 16, with a weaker warning below 8. Both modes draw with getRandomValues in the current tab. Copy uses writeText. There is no account and no password vault. What you verify is the permission prompt, Win+V, and a paste on the other device — not the word “Copied” on the page.

How to close the window after you paste

For the one string you must copy today, finish in this order: confirm focus is in the right password field, then paste; immediately copy a junk character or clear history in the system panel; if someone else needs the secret, switch to a one-time link and keep the key after # instead of leaving plaintext on the clipboard “as a backup.” For accounts a manager can fill, take Copy out of the workflow.

Treat a shared PC, a demo machine, and a jump host with remote desktop open as “a second person can read this clipboard.” Do not copy a master password there. When you must type, a longer readable passphrase cuts typo risk — then rotate it after use. Four words from a 100-word list are only about 27 bits, too weak for a master password; the comparison is in Random password vs passphrase: four words are not automatically strong.

Once you overwrite after paste and refuse Allow on a read prompt, you can already answer the article’s question. Who can still read after Copy depends on web permission, OS history, cloud sync, a remote session, and your next paste. A generator that does not upload only means the server log does not hold that string. It does not take back the copy the operating system already handed out.

FAQ

Does HTTPS already protect a password after I copy it?

No. HTTPS protects the hop from the browser to a server. The clipboard is local. It does not ride that TLS session. A page upload, OS history, Universal Clipboard, and a mis-paste do not care whether the address bar shows a padlock.

If I clicked Allow on clipboard read, can I take it back?

In Chromium, yes: site settings → permissions → Clipboard → Block. Firefox and Safari usually do not store that read as a lasting grant, so the next attempt still goes through the Paste item. Do not grant read to an origin you do not trust just to click one fewer time.

Do I need an account to generate a password? Does Copy upload it?

No account. Generation and copy should stay in the current tab. Copy writes the string into the system clipboard. It is not a POST to a server. Open Network: after Copy, the request body and analytics events should not contain that password. When a colleague needs a copy, use a one-time link. Do not treat the clipboard as a transport channel.

Is password-manager autofill safer than copy?

For “one fewer trip through the system clipboard,” yes. Autofill puts the password into the current form and skips the Win+V history. If the manager still offers Copy, that copy uses the same buffer as a generator page, and you still need to overwrite. If autofill is available, do not copy.