Can websites read your clipboard?

It is a fair worry: you copy a password or a bank detail, then open a website, and you wonder whether that page just read what is on your clipboard. The answer is reassuring in the ways that matter and more interesting in the ways that do not. Browsers expose a clipboard API to web pages, but they wrap it in guardrails specifically so a random site cannot reach into shared memory and slurp up whatever you last copied. The bigger everyday risk turns out to be something quieter, and we will get to it.

This piece zooms in on the browser. For the wider picture of what software on your machine can see, start with the overview, is your clipboard a security risk?

Can a website read your clipboard? The short version

Reading the clipboard from JavaScript is done with navigator.clipboard.readText(). It looks simple, but it only works when several conditions line up at once, and those conditions are the whole point.

• A secure context. The page has to be served over HTTPS. A plain HTTP page cannot use the asynchronous clipboard read at all.
• The document must be focused. The tab has to be the active, focused one. A background tab cannot read the clipboard, so a site you opened and forgot about is not quietly watching.
• A permission gate.In Chromium browsers, Chrome, Edge, and friends, reading triggers a “clipboard-read” permission prompt the first time. Firefox asks differently, with a paste-confirmation button on every read. Either way, if you do not approve it, the read fails.

Put together, that means a web page cannot silently poll your clipboard in the background and exfiltrate everything you copy. It needs to be the page you are looking at, on HTTPS, and in Chromium it needs your say-so. That is a meaningful set of brakes.

The real way sites see what you copied

Here is the part that actually matters day to day, and it has nothing to do with the read API. When you paste something into a page, the page receives it. A paste event hands the site exactly the text you dropped in, by design, because that is what pasting is for. No permission prompt, no API, no trickery: you chose to put that text into that field.

So the genuine risk is not a website reaching into your clipboard uninvited. It is pasting the wrong thing into the wrong place. Paste a password into a search box, or into the username field, or into a chat window you meant to close, and that page now has your secret because you handed it over. This is the everyday failure mode, and it is also why we wrote a dedicated guide, is it safe to copy and paste passwords?

Writing is easier than reading, and that is where pastejacking lives

Browsers are stricter about reading the clipboard than about changing it. Sites legitimately write to the clipboard all the time: the “copy” button next to a code snippet, a coupon code, a share link. That convenience has a shadow side called pastejacking, where a page makes sure that what lands on your clipboard is not quite what you thought you copied.

The classic example is a tutorial page with an install command. You click “copy,” expecting something like curl https://example.com/install.sh | sh. But the page quietly put a longer line on your clipboard, maybe the same command with an extra instruction appended after a newline. You paste into your terminal, and because a trailing newline can make a shell run the line immediately, the extra part runs before you have read it. Nothing “read” your clipboard here. The page wrote to it.

This is not a reason to panic about copy buttons, which are overwhelmingly benign. It is a reason for one specific habit: before you paste a command into a terminal, paste it into a plain text editor first, or at least read the whole line, and never let it auto-run. Terminals are the one place where a surprise in the clipboard turns directly into executed code.

Why browsers and devices differ

The clipboard API is not implemented identically everywhere, and the differences shape what a page can actually do.

Chromium (Chrome, Edge)

Chromium offers the full asynchronous read, gated behind the secure context, focus, and the clipboard-read permission prompt described above. This is the most permissive of the major engines, and also the one that asks you first.

Firefox

For years Firefox refused to expose the asynchronous clipboard read to web pages at all. That changed in 2024: Firefox 125 added support for navigator.clipboard.readText(), gated behind its own style of consent. Instead of a remembered site permission like Chromium’s, Firefox shows a small paste-confirmation button each time a page asks to read, and the page only receives the text if you click it. No click, no read, and there is no way for a site to pre-approve itself.

Safari and mobile

Safari requires a clear user gesture, a deliberate action tied to the read, rather than letting script read on its own. On phones the rules are tighter across the board. Mobile operating systems already guard the clipboard at the system level, iOS shows a banner when an app reads it, and mobile browsers inherit that cautious posture. If a behavior is going to be blocked anywhere, it is usually blocked on mobile first.

Practical guidance that actually helps

You do not need to fear the browser. You need a few small habits that match where the real exposure is.

• Do not paste secrets into pages you do not trust. The paste itself is the handover. If you are not sure a site should have a value, do not paste it there. For moving a secret to someone safely, a burn-after-reading private note beats pasting it into a random form or chat.
• Re-read before pasting into a terminal. Drop copied commands into a text editor first, check the whole thing, and never let a pasted line auto-run. This defuses pastejacking entirely.
• Keep your browser updated. The clipboard guardrails live in the browser, and they get tightened over time. An out-of-date browser is the one most likely to have a loophole.
• Be careful with extensions. A web page is boxed in by the API rules. A browser extension you have installed can be far more dangerous, because it may be granted broad access to page content and, depending on its permissions, the clipboard, with no per-use prompt. Install few, from sources you trust.

If you want the full device-by-device checklist that goes beyond the browser, that lives in how to keep your clipboard private. The browser is only one surface, and the same calm habits, paste deliberately, re-read commands, stay patched, apply everywhere your clipboard goes.

Frequently asked questions