The clipboard is one of those OS-level resources web apps have historically had no clean access to. The navigator.clipboard API changes that—with one non-negotiable caveat: the user must grant permission first.
That is the right design. Clipboard contents can be anything: passwords, addresses, private messages. Unfettered read access would be a security disaster.
The short version
- Navigator.clipboard requires explicit user permission
- The permissions API exposes clipboard-read and clipboard-write scopes
- Read() returns a ClipboardItem with type information
- ReadText() is the shortcut for plain text only
- Images and rich text show up as additional MIME types in the type list
How the permission flow works
You ask for clipboard access through the permissions API. Query for "clipboard-read" or "clipboard-write" depending on what you need. The browser returns a state: "granted", "denied", or "prompt". "prompt" means the user has not decided yet; you can request a permission prompt on the next interaction.
The "clipboard-write" scope is generally easier to get than "clipboard-read". Writing to the clipboard is low-risk. Reading from it is high-risk. Browsers lean conservative on the latter.
Reading the clipboard contents
Once you have permission, navigator.clipboard.read() returns an array of ClipboardItem objects. Each item has a types property that lists the MIME types available. Plain text copies show up as ["text/plain"]. Image copies from a website show up as ["text/html", "image/png"].
If you only need plain text, use readText() instead. It skips the ClipboardItem dance entirely.
For images, the path is more involved. You need the MIME type, pull the blob from the item, build a data URI, and feed that to an <img> element for display.
Our analysis: what this means in practice
Clipboard read access is genuinely useful in specific contexts—screenshot tools that paste into an editor, image cropping utilities that grab whatever is in your clipboard, rich text processors that handle mixed content.
The trade-off is real. A webpage that reads your clipboard on every focus event would be a privacy catastrophe. The permission gate exists because the data is sensitive by default. The asymmetry between read (harder) and write (easier) reflects actual risk: most web apps need to write to the clipboard, few genuinely need to read from it.
The current implementation is a reasonable compromise. The permission prompt is intrusive enough that users notice when it appears, which discourages casual abuse. But it does mean developers must design the interaction deliberately. A read triggered on page load fails silently. A read triggered on a button click surfaces the prompt correctly and gives the user context for why they are being asked.
If you build with this API, treat clipboard contents as untrusted input—exactly as you would treat any user-supplied data.
Who should care
Build this into your app if you are making:
- Screenshot or image annotation tools
- Rich text editors that handle pasted content
- Content remix tools that grab external images for processing
Do not bother unless:
- You need to process mixed clipboard content automatically
- Your users frequently paste between specific web and desktop workflows
- You are replacing a native app with a web equivalent
Skip entirely if:
- Your app only needs to read typed input from a text box
- Your users are comfortable pasting manually into your interface
Worked example: building a paste-to-display tool
Say you want a web tool that displays whatever the user copies. Wire a "Paste" button to navigator.clipboard.read(). Check the types array for "image/png" or "image/jpeg". If present, pull the blob, build a data URI, and render it in an <img> element.
For text pastes, use readText() in the same click handler. Branch on the detected type.
Always gate the read behind a button click. Browser permission prompts are triggered by user gestures; a prompt that appears without one is rejected silently. This is also the right UX: the user understands why they were prompted.
Treat whatever comes back as untrusted. Validate image MIME types server-side if you ever upload. Sanitise text input the same way you would for any user-supplied string.
What to watch next
The clipboard API is stabilising but not universal. Always feature-detect before calling.
The async Clipboard API also has a write side. Navigator.clipboard.write() accepts a ClipboardItem and can write arbitrary blobs back to the clipboard. The use cases are fewer but include web apps that generate images and want to let users copy them out.
Key takeaways
- Read access requires explicit user permission; write access is easier to obtain
- Detect MIME types from ClipboardItem.types before deciding what to do with content
- Always trigger reads from a user gesture to surface the permission prompt correctly
- Treat clipboard contents as untrusted input, same as any user-supplied data
Frequently asked questions
Does the clipboard API work in all browsers?
Most modern browsers support it. Always feature-detect before calling to avoid runtime errors.
Can websites read my clipboard without permission?
No. The permissions API requires the user to grant access before any read can occur.
What is the difference between read() and readText()?
Read() returns a ClipboardItem with type metadata, which lets you handle images and rich text. ReadText() is a shortcut that returns only the plain text content.
Can I write to the clipboard without a permission prompt?
The write scope is easier to obtain than read, but gating writes behind a user gesture is still best practice.