Learning

Reading from the clipboard: readText, the permission prompt, and the focus rule

A placeholder lesson on clipboard reads: why readText is gated behind a permission, what the focus rule prevents, and how reads differ from writes in the security model.

Levels: Intermediate ~12 min read

Intermediate

Why reads are gated harder than writes

Writing to the clipboard can only overwrite what the user placed there. Reading from it can exfiltrate it. That asymmetry is why navigator.clipboard.readText() resolves only after the browser is satisfied on two fronts: the page holds the clipboard-read permission (granted, denied, or prompted), and the document currently has focus.

The focus rule closes a hole that the permission alone would leave open: a background tab that already holds permission cannot silently harvest the clipboard while the user copies a password into a completely different application. No focus, no read — the promise rejects instead.

Reading richer data and handling rejection

The symmetric read() returns ClipboardItem objects whose types you should check before use — a paste target that expects PNG may receive plain text, and the API reports what the source application wrote, not what your handler hopes for. Handle rejections explicitly: a denied permission is a normal outcome, not an exceptional one.

Quick check

A background tab holds the clipboard-read permission. The user copies a URL while working in another app. What happens when the tab calls readText()?

// document.hasFocus() === false
await navigator.clipboard.readText();
// result: ?

Key takeaways

Reads are gated by permission and document focus; writes only need transient activation.
A denied permission is a normal result your code should handle gracefully.
read() returns ClipboardItems whose types you must verify before consuming.

Was this page helpful?

Yes No

Mark this learning resource complete to track your learning progress.