Clipboard Paste Button — Free navigator.clipboard Read & Write

This snippet pairs a "Paste from clipboard" and a "Copy" button around a single text input, wired to the real navigator.clipboard API's readText() and writeText() methods. Clipboard access is a permission-gated capability — it needs a secure context, is often scoped to a user gesture, and is one of the APIs most commonly blocked entirely inside a sandboxed preview iframe — so the design goal here is that the input is a fully working text field regardless of whether the Clipboard API cooperates.

Reading the clipboard

pasteFromClipboard() first checks navigator.clipboard && navigator.clipboard.readText exists, then calls it inside a try/catch. On success, the resolved string fills the input directly. On a rejection — almost always a NotAllowedError from a denied permission prompt or a blocked clipboard-read permissions policy — an inline message appears explaining exactly that, and directs the viewer to the keyboard shortcut instead. The input is never disabled; a real Ctrl/Cmd+V paste always works independent of the button, because that's a native browser behavior the Clipboard API doesn't gate.

Writing the clipboard

copyToClipboard() mirrors the same shape: try navigator.clipboard.writeText() first, and if it's unavailable or throws, fall back to the classic technique of selecting a temporary off-screen <textarea> and calling document.execCommand('copy'). Only if that also fails does the UI ask the viewer to select the field and copy manually — and even then, it calls input.select() for them so the manual step is one keystroke, not a hunt.

Inline, not silent, failure

Every failure path writes a specific, visible sentence into an inline message element rather than failing silently or logging to the console. That's the same honesty principle behind this library's canvas audio frequency bars snippet, which names the exact getUserMedia error rather than just switching modes quietly — a viewer should always be able to tell why a permission-gated demo is behaving the way it is.

A field that never breaks

Because the <input> is a normal, always-editable form control, none of this matters to someone who simply types their value in or uses their OS's native copy/paste shortcuts. The Clipboard API only ever adds convenience buttons on top of a baseline that already works — which is the right way to layer a flaky permission-gated capability onto a form. Pair it with a plain copy button for a simpler one-directional case, or a Web Share button for sharing instead of copying.

Customizing it

Swap the input for a textarea to paste larger blocks, add a "clear" button, or validate the pasted value (e.g. a tracking-number format) before accepting it.